FAIL (the browser should render some flash content, not this).

intwayblog.netДвижок для блогаWordPress → Каким должен быть идеальный WordPress

Каким должен быть идеальный WordPress

шаблоны wordpress

В 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

    Первый - неудачный встроенный механизм перевода, не позволяющий рядовому пользователю самому быстро исправить файл перевода и, второй - использование кодировки UTF-8

     



Добавьте комментарий:
Ваше имя:
E-mail: