3 вещи, которые произойдут с WordPress в ближайшем будущем
В WordPress появится управление зависимостями
С этим пунктом не может быть вопросов. WordPress определенно требуется механизм управления зависимостями. Все мы видели, что в других областях PHP, и даже в других языках, активно используются менеджеры зависимостей. Скорее всего, в WordPress будет принят Composer – либо из коробки, либо в результате некоторой настройки.
Что представляет собой менеджер зависимостей?
Менеджер зависимостей – это программный инструмент, который позволяет управлять зависимостями (другими библиотеками), требуемыми для уже существующих библиотек. В PHP-мире используется Composer. Каждая PHP-библиотека, которая поддерживается Composer, будет иметь определенный набор зависимостей. Роль Composer состоит в том, чтобы получить все эти зависимости и убедиться в том, что они совместимы друг с другом.
Почему в WordPress это требуется?
В WordPress требуется менеджера зависимостей, чтобы не приходилось всякий раз изобретать колесо, когда нам нужно создать плагин или тему. Всякий раз, когда мы пишем код под WordPress, учитывая, что уже существует подобный PHP-пакет, мы просто впустую тратим время. Использование сторонних зависимостей позволит ускорить разработку и добиться более высокой безопасности. Проблемы с безопасностью WP-плагинов, которые выявляются снова и снова – то, что можно было бы частично решить введением менеджера зависимостей.
Что это значит для вас?
Принятие менеджера зависимостей в WordPress будет означать для разработчиков плагинов следующее: у них появится возможность создавать WordPress-плагины для всех существующих PHP-библиотек. Когда это произойдет, мы увидим сотни, если не тысячи, плагинов, которые будут являться простой WordPress-оберткой уже существующих библиотек. Некоторые из этих плагинов станут очень популярными. Готовьтесь к этому заранее, если вы – будущий автор плагинов.
Разработчики WordPress, скорее всего, также столкнутся с некоторым типом фронтэнд менеджеров зависимостей, поскольку с выходом WP REST API многие вещи, затрагивающие фронтэнд, будут кардинальным образом изменены. В следующем разделе мы подробнее об этом поговорим.
WordPress станет просто бэкэндом
Это не моя идея, однако я считаю, что это – тот путь, по которому мы идем. С появлением WP REST API в ядре, WordPress станет просто бэкэндом, дополненным управлением пользователями и т.д., который будет использоваться для API-основанных веб-приложений. Темы будут строиться на JavaScript и будут взаимодействовать с WordPress через API. Плагины останутся по большей части на PHP с примесью JS, так же, как и сам бэкэнд.
Я полагаю, что главная причина такого широкого успеха WordPress – это консоль. Она очень удобна для пользователей и интуитивно понятна. Стоит также добавить, что вы можете легко устанавливать плагины и темы. Расширение ядра также является тривиальным действием, поскольку все хуки и фильтры встроены в ядро WordPress. WP REST API не будет менять это. Он просто добавит дополнительный уровень для фронтэнд-разработчиков, в результате чего, как мне кажется, будет радикально изменен процесс создания тем.
Несколько лет назад я работал как Ruby on Rails разработчик. Для одного из проектов нам нужна была CMS, которая позволяла бы управлять контентом нашего Rails-приложения. Мой друг, один из разработчиков на Ruby, предложил мне использовать консоль WordPress в качестве бэкэнда, создав для нее простой API. Тогда мы этого не сделали, однако представьте, как просто было бы это реализовать, если бы тогда уже был такой API.
Что это значит для вас?
Если вы являетесь разработчиком WordPress, то в будущем это будет означать, что вы, скорее всего, уже не будете WordPress-разработчиком. Вы будете «просто» разработчиком тем. Лучше всего подтяните свои JS-навыки перед тем, как это случится.
WordPress станет менее целостной и более модульной
Как результат всего этого, WordPress станет менее целостной. Очевидно, что самый крупный разрыв пройдет между бэкэндом (консоль и плагины) и фронтэндом (темы). Также можно предположить, что с вводом Composer ядро само по себе станет менее целостным. Возможно, это будет напоминать то, как фреймворк Laravel разбит по пакетам Illuminate (хотя теперь нам нужно будет определить, что подразумевать под «ближайшим будущем»).
Как уже было упомянуто ранее, основным компонентом станет консоль. Плагины, скорее всего, останутся частью консоли, однако в будущем они могут больше походить на пакеты Composer, заточенные под WordPress. Лучше всего оставить их на PHP – естественно, с некоторым добавлением Javascript.
Если Composer будет принят в ближайшем будущем, то понадобится обновить минимальные требования к PHP-версиям. Это, скорее всего, произойдет очень скоро. Возможно, мы увидим фронтэнд-плагины, однако они будут написаны на Javascript, и управление ими будет производиться через фронтэнд менеджер зависимостей.
Что это значит для вас?
Это означает, что если вы являетесь автором плагинов WordPress, вы можете продолжать писать старый добрый PHP-код. В данный момент не нужно переходить сразу на NodeJS, но если вы являетесь разработчиком тем, вам полезно следить за всем этим.
Также это означает, что WordPress станет менее целостной и более настраиваемой. Вы сможете выбрать те компоненты, которые вам требуются, и отбросить все остальное. Если вам нужно что-то еще, вы можете найти существующий пакет PHP, позволяющий решить поставленную задачу. Звучит прекрасно, верно?
Источник: wptavern.com
