В WordPress'е удачно реализованы множество идей, например плагины или шаблоны, что выводит «движок» в лидеры по использованию. Но, при всём этом я всё-таки далек от мысли, что текущая версия идеальна. Я не имею ввиду непосредственно программирование - речь идет о структуре (архитектуре) WordPress. Я решил порассуждать на тему идеального WordPress: каким бы я хотел его видеть: что можно оставить без изменений, а что требует переделки.

Шаблоны

Начну, пожалуй с того, что работает без нареканий. Поддержка шаблонов реализована очень удачно. Я уже писал, что возможности WordPress ограничены возможностями PHP. Это достигается и благодаря тому, что в шаблонах выполняется «чистый» PHP, а не парсинг текста, как это делается во многих других «движках». Поэтому, если нужно добавить свою функцию, не требуется идти ни на какие ухищрения.

Плагины

Поддержка плагинов реализована грамотно. Единственное чтобы хотелось, так это в параметрах (в таблице options) нужно автоматически помечать его принадлежность к конкретному плагину. Это позволит не загружать опции отключенных плагинов. В идеале же каждый плагин должен проходить процедуру инсталяции (первой активации) и деинсталяции с удалением созданных параметров из базы данных.

База данных

Класс для работы с базой данных отточен уже довольно сильно, поэтому переделки вряд ли потребует. Лично я файл wp-db.php использую и для других своих проектов. Что же касается структуры самих таблиц, то они всё равно будут меняться от версии к версии.

Кэш

Кэш вызывает двоякое чувство: с одной стороны он демонстрирует свою эффективность, а с другой - очень уж запутанный код для использования получился. В идеале хотелось бы получить управляемый кэш, в который можно добавить буквально одной строчкой любой текст, массив или параметр. Понятно, что использование кэширования целиком ложится на разработчика, и сейчас можно вполне успешно это делать, но пока еще слишком много подводных камней.

XML-RPC

Поддержка XML-RPC используется в WordPress уже давно. Он поддерживает основные команды разных блоговских API. С этим проблем нет. Но существует проблема расширяемости: для того, чтобы добавить свою функциональность придется серьезно переделать xmlrpc.php. Кроме этого здесь используются функции самого WordPress, например при публикации с помощью XML-RPC, данные передаются не только в xmlrpc.php, но и дальше по «цепочке» срабатывают функции WordPress. Теоретически так и должно работать, но на практике оказывается, что возвращаемый результат должен быть разным (например, когда осуществляется кроспост в ЖЖ). В этой связи было бы лучше отделить функции для XML-RPC в отдельный блок.

И совсем уж в идеале я хотел бы увидеть реализацию API именно для WordPress, чтобы можно было бы не только публиковать записи, но и полностью управлять блогом.

Админы и юзеры (участники)

На мой взгляд, лучше было бы разделить текущую админ-панель на две части: первая для администратора, другая - для участников. Администратор получает доступ ко всем настройкам сайта, которые не треубются для публикации записей.

Участники, же получают доступ только к той части, которая требуется для написания заметки. В зависимости от уровня доступа у них будет возможность добавлять новые рубрики, ссылки, файлы и т.п. При этом администратор может выставить премодерацию для любого участника.

Редактор

Если разделить админ-панель, то можно без особых проблем сделать возможность написания статей любым посетителем. По большому счету, ему даже регистрация не потребуется - если администратор разрешил, то он может сразу войти в текстовый редактор и создать нужную заметку. В какой-то мере это аналог Wiki.

Кроме этого, такое разделение позволит использовать и сторонний текстовый редактор. Сейчас их довольно много и многие демонстрируют большую функциональность, чем встроенный TinyMCE. Для примера FCKeditor позволяет приблизить редактор к уровню Word'а.

Сейчас же единая админ-панель привела к несколько «странному» появлению «ролей пользователей». При этом изменить «роль» довольно проблематично. В этой связи, в идеальном WordPress'е нужно полностью изменять подход к управлению участниками и их модерированию.

Конфигурация

Вынос некоторых настроек в админ-панель, лично мне видится очень странным. Все основные настроики блога можно совершенно безболезненно перенести из админ-панели в отдельный конфигурационный файл. Указание кодировки, путей, формат времени, часовой пояс и т.д., и т.п. меняются очень редко, и обычно указываются один раз в момент установки блога. Поэтому хранить их в базе данных и получать в виде отдельных функций, не совсем удачная идея. Если же нужна интерактивность, то лучше было бы сделать редактор конфигурационного файла: после изменений файл записывается на диск. Для получения например, кодировки достаточно взять значение переменной или элемент массива.

Кодировки

WordPress позволяет работать с любой кодировкой. Но для этого требуется дополнительно внести некоторые коррективы в сам «движок». Скажем баг с неуказанием кодировки трэкбаков до сих пор не устранен. Недавняя проблема с добавлением рубрики (через AJAX), тоже говорит о том, что использование кодировки, отличной от UTF-8, может привести к появлению нечитабельного текста.

В идеальном WordPress'е должен быть отдельный модуль для работы с кодировками. При работе с AJAX, можно было бы просто конвертировать передаваемые данные в UTF-8 (в этой кодировке работает AJAX), а результат получать в кодировке блога. Если такой блок будет реализован, то написание AJAX-приложений для WordPress в любой кодировке не будет большой проблемой.

Локализация

Существующий (стандартный) подход к локализации можно критиковать очень долго. По большому счету он просто негоден к употреблению для проектов с более-менее серьезной посещаемостью. Большая часть перевода предназначена только для админ-панели, но всё равно подгружается при каждом вызове страниц.

Я хотел бы видеть в WordPress'е разделение файлов перевода для разных частей блога. Например, для файлов wp-admin, это будет один файл, для плагинов - другой, для функций - третий. Таким образом можно значительно облегчить нагрузку на сервер.

Также я бы хотел увидеть несколько другой принцип построения файла перевода: примерно такой, как я использую в wp-language.php. Если написать несколько дополнительных функций, то добавлять перевод к уже существующему будет очень просто: например для того, чтобы русифицировать плагин достаточно будет только внести этот перевод в глобальный массив.

В заключении

Сейчас готовится версия WordPress 2.1. Я очень надеюсь, то она станет базой для будущих, и «продержится» достаточно долго, чтобы разработчики смогли его освоить и предложить свои наработки. Наверное, это и будет очередной шаг к идеальному WordPress'у.

]]> ]]>