Разработка шаблона плагина WordPress

[sergey-s-betke]

В этой задаче опишу для цели и соберу необходимый материал.

Цели:

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

[sergey-s-betke]

Приведу ссылки на другие проекты github:

• https://github.com/Emerson/Sanity-Wordpress-Plugin-Framework
• https://github.com/iandunn/WordPress-Plugin-Skeleton

P.S. Наткнулся на любопытный плагин, позволяющий обновлять установленные плагины с их репозиториев в github - https://github.com/jkudish/WordPress-GitHub-Plugin-Updater

[sergey-s-betke]

Этот проект на первом этапе будет содержать весь код шаблона. На последующих этапах библиотека классов будет выделена в отдельный репозиторий, и будет включена в этот проект уже через подключение репозитория.

[sergey-s-betke]

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

Для исключения повторной загрузки файлов целесообразно реализовать автозагрузчик для классов.

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

[sergey-s-betke]

Теперь пару слов о структуре плагина.

Основной файл плагина - не более, чем загрузчик. В нём мы должны проверить версию wordpress, PHP, прочих компонентов, и не более. Другими словами, код в этом файле должен быть работоспособен в идеале на wordpress 3.0. Посему - никаких namespace здесь и прочих прелестей.

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

Итак, в основном файле мы повесим только hook'и - и не более:

• на активацию
• на деактивацию
• на удаление
• на обновление
• ну и на init - по этому событию собственно и будем создавать объект плагина плагина

Инициализация плагина предполагается по событию init (http://codex.wordpress.org/Plugin_API/Action_Reference). Но ряд событий до этого момента уже предполагают некоторые действия со стороны плагина (больше - регистрационные, регистрация типов постов, таксономии и так далее).

[sergey-s-betke]

В итоге - должна быть некая фабрика, которая будет манипулировать с рядом классов и объектов в плагине. Потому как на этапе активации, деактивации и удаления собственно сам код плагина (который при загрузке может вызвать и ошибку) грузить не стоит, но при этом уже с параметрами, вспомогательными каталогами и так далее уже необходимо уметь работать. То есть они должны быть описаны где-то отдельно от класса плагина.

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

[sergey-s-betke]

Итак, структура:

• отдельно создаём экземпляр описателя плагина. Это не фабрика! (admin / frontend)
• коллекция опций, без интерфейса, но с валидаторами (admin / frontend)
• настройки плагина, страница настроек (admin)
• ну и нечто, что будет отвечать за активацию, деактивацию, удаление, обновление.

[sergey-s-betke]

Как вариант, в основном параметре плагина можно регистрировать всё, что необходимо будет удалить при деинсталляции.?

[sergey-s-betke]

Эту задачу закрываю. Версию 0.1 можно считать практически завершённой.