Как вы организовываете свои плагины и код темы? - PullRequest
0 голосов
/ 19 июля 2010

Я начал работать с WordPress в качестве CMS, теперь, когда V3 упрощает управление таксономиями и пользовательскими типами записей.Моя работа в основном сосредоточена на разработке плагинов и тем.

Мой самый большой плагин выполняет некоторые функции администратора (добавляет элементы меню администратора и связанные страницы и функции), но также выполняет некоторые операции импорта и экспорта, а также перехватывает некоторые из них.базовые процедуры постобработки («при ​​создании нового поста»).

Моя самая большая тема довольно маленькая, и все, что она делает, это отображает пользовательские посты в индивидуальном порядке.

Через нескольконедели работы, у меня есть несколько тысяч LoC, и мне становится все труднее и труднее в этом разобраться.Что приводит меня к следующему вопросу: Как вы организуете свой код плагинов WP?А как насчет кода вашей темы WP?

Ответы [ 4 ]

4 голосов
/ 19 июля 2010

несколько тысяч LoC

Это довольно эпично! Я всегда находил прелесть WP в том, что могу, как выразился jQuery;

Пишите меньше, делайте больше!

Возможно, вам гораздо лучше использовать Pods CMS вместе с WP, чтобы сократить ваш код.

3 голосов
/ 09 апреля 2012

Так мы структурируем клиентские развертывания, которые включают темы, сторонние плагины и пользовательский код.

  • wp-content / plugins содержит только сторонние плагины, ни один из приведенных здесь кодов не изменяется, и сайт не должен быть заблокирован ни одним из этих плагинов, которые были отключены / удалены.
  • wp-content / themes должен содержать код, связанный с представлением внешнего интерфейса.Хитрость заключается не в том, чтобы не перегружать тему (functions.php и другие связанные с темой файлы) кодом, не связанным напрямую с презентацией.
  • mu-plugins / содержит всю вашу бизнес-логику, специфичную для реализации.Вещи здесь никогда не должны быть отключены, и необходимы для операций.

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

0 голосов
/ 06 июня 2012

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

Другой «правильный» способ, который часто рекламируется, - это наличие одного гигантского класса со всем вашим кодом плагина. Как вы и сказали, сохраняя все в порядке, как только этот файл попадет в тысячи строк кода, вам не хватает управляемости.

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

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

Надеюсь, я помог!

0 голосов
/ 19 июля 2010

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

...