Банальный plugin php. Лучший способ разрешить плагины для PHP-приложения

22.03.2019

8 ответов

Вы можете использовать шаблон Observer. Простой функциональный способ выполнить это:

Вывод:

This is my CRAZY application 4 + 5 = 9 4 * 5 = 20

Примечания:

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

Это всего лишь один из способов создания плагиновой системы в PHP. Есть лучшие альтернативы, я предлагаю вам ознакомиться с документацией WordPress для получения дополнительной информации.

Извините, похоже, символы подчеркивания заменяются объектами HTML Markdown? Я могу повторно опубликовать этот код, когда эта ошибка будет исправлена.

Edit: Nevermind, он появляется только тогда, когда вы редактируете

Итак, скажем, вам не нужен шаблон Observer, потому что он требует, чтобы вы изменили методы класса для обработки задачи прослушивания и хотите получить что-то общее. И скажем, вы не хотите использовать наследование extends , потому что вы уже можете наследовать свой класс из какого-то другого класса. Было бы здорово иметь общий способ сделать любой класс подключаемым без особых усилий? Вот как:

Я считаю, что самый простой способ - следовать советам Джеффа и взглянуть на существующий код. Попробуйте посмотреть на Wordpress, Drupal, Joomla и другие известные PHP-CMS, чтобы посмотреть, как выглядят и ощущаются их API-интерфейсы. Таким образом, вы даже можете получить идеи, о которых вы, возможно, раньше не думали, чтобы сделать вещи немного более густыми.

Более прямой ответ заключался бы в том, чтобы написать общие файлы, которые они бы включили в include файл, чтобы обеспечить удобство использования. Это будет разбито на категории и НЕ предоставлено в одном файле "hooks.php" MASSIVE. Будьте осторожны, потому что то, что заканчивается, заключается в том, что файлы, которые они включают, в конечном итоге имеют все больше и больше зависимостей и функциональности. Попытайтесь ограничить зависимость API. I.E меньше файлов для их включения.

Практически каждый, кто ведет блог на WordPress и самостоятельно занимается его обслуживанием, знает о существовании волшебного файла functions.php. Часто его применяют абсолютно не по назначению, что может привести к существенным проблемам. Давайте вместе более детально разберемся с этим вопросом.

Уверяю, прочитав эту статью, Вы измените свое отношение к плагинам и перестанете пополнять ваш functions.php очередным сниппетом кода.

Плагины и functions.php

Многие владельцы сайтов на WordPress твердо убеждены, что плагины непременно будут нагружать и тормозить блог. А если просто добавить код в functions.php, то это никак не повлияет на нагрузку. Увы, это не совсем так…

Дело в том, что нагрузку вызывает не конкретно плагин, а его неверно написанный код, который, легко может попасть и в functions.php из очередного руководства.

Давайте посмотрим в чем главные отличия плагина и functions.php.

Принципиальное отличие плагина от файла functions.php — в назначении и порядке выполнения.

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

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

Если Вы обычный блоггер и далеки от веб-разработки, то при выборе плагина обязательно обращайте внимание на отзывы в репозитории WordPress и на блогах авторов или веб-разработчиков.

Если все еще остались сомнения — сделайте чашечку кофе и обязательно прочтите статью Константина Ковшенина на WP Magazine — «Вся правда о functions.php ». В первой части просто и доступно рассказывается почему не стоит верить в мифы о functions.php.

Плагин как альтернатива файлу functions.php

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

Давайте создадим свой плагин — альтернативу файлу functions.php. Не стоит пугаться, он будет выглядеть один в один как любимый functions.php 🙂 . Все, что потребуется — просто добавить пустой плагин на свой сайт. И затем в него можно вставлять необходимый код, как раньше делали это c functions.php.

Прежде всего нам нужно создать на компьютере файл с названием functionsphp.php и добавить в него следующий код:

.

Плагин Exec-PHP есть в репозитарии и устанавливается через меню в админке движка.

Из настроек есть только одна – разрешение/запрет на исполнение кода в текстовом виджете, возможности отключить работу в постах и на страницах отсутствует, если надо ее убрать – деактивируем плагин.

Для вставки PHP кода в статью, должен быть переведен в HTML режим (вкладка «Текст»). Визуальный режим, скорее всего, код попортит.

Выполнение PHP кода в статьях WordPress без плагина

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

Как работать с описанной ниже функцией

  • Вставляем ее в файл functions.php темы;
  • В нужном месте статьи вставляем конструкцию – исполняемый код без
  • Функция:

    /* Запуск php в статьях и страницах WordPress: код */ function start_php($matches){ eval("ob_start();".$matches."$inline_execute_output = ob_get_contents();ob_end_clean();"); return $inline_execute_output; } function inline_php($content){ $content = preg_replace_callback("/\((.|\n)*?)\[\/startphp\]/", "start_php", $content); $content = preg_replace("/\((.|\n)*?)\[\/startphp\]/", "$1", $content); return $content; } add_filter("the_content", "inline_php");

    /* Запуск php в статьях и страницах WordPress: код */

    function start_php ($matches ) {

    eval ("ob_start();" . $matches [ 1 ] . "$inline_execute_output = ob_get_contents();ob_end_clean();" ) ;

    return $inline_execute_output ;

    function inline_php ($content ) {

    $content = preg_replace_callback ("/\((.|\n)*?)\[\/startphp\]/" , "start_php" , $content ) ;

    $content = preg_replace ("/\((.|\n)*?)\[\/startphp\]/" , "$1" , $content ) ;

    return $content ;

    add_filter ("the_content" , "inline_php" ) ;

    Недостаток

    Если внутри вставляемого PHP кода есть HTML вставки или текст, то он работать не будет. Любой текст или теги придется вставлять с помощью команды echo, что не всегда удобно. То есть, код должен быть чисто PHP-шный на 100 правильного формата.

    Правильно

    Echo "Так работать будет";

    [ startphp ]

    echo "Так работать будет" ;

    [ / startphp ]

    Неправильно

    Echo "Эта строка правильная"; Так работать не будет

    [ startphp ]

    echo "Эта строка правильная" ;

    < a href = "https://сайт" > Такработатьнебудет< / a >

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


    Конечно, проще и привычнее пойти традиционным путем и тупо вставить сниппет в файл functions.php вашей активной темы. Но в 9 из 10 случаев будет целесообразнее и правильнее вынести код сниппета в отдельный плагин . В крайнем случае, добавить его в специальный функциональный плагин вашего сайта. Т.н. Site-Specific WordPress Plugin , в котором-то и будет храниться весь дополнительный функционал вашего сайта.

    Зачем это нужно

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

    Как же быть

    Нужно понять простую истину. В файле функций темы должны располагаться только функции, относящиеся к дизайну вашего сайта. Конкретно к той теме, файл функций которой редактируется. А вся т.н. «механика», рабочий функционал сайта и все его кастомизации правильнее размещать в плагинах. Или в одном плагине. Тогда при смене темы, он останется нетронутым.

    Создаем специальный плагин функций WordPress

    На самом деле, все делается очень просто.

    • В директории плагинов вашего WordPress создаете папку. Например: /wp-content/plugins/mysite-plugin/ ;
    • Создаете в этой папке файл, назвав его, к примеру, my-plugin.php ;
    • Вставляете в этот файл примерно такой код:
    • Переходите в настройки управления плагинами и активизируете свой новый плагин.

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

    На этом можно и остановиться, но с моей стороны было бы не совсем правильно не упомянуть про т.н. MU-плагины .

    MU-плагины (Must Use Plugins)

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

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

    Преимущества MU-плагинов
    • MU-плагины не нужно активировать, они всегда активны, их невозможно отключить в консоли управления сайтом;
    • MU-плагин подключается и активируется банальной закачкой файла плагина в директорию mu-plugins;
    • MU-плагины загружаются в алфавитном порядке перед загрузкой обычных плагинов.

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

    В заключение

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

    Всё самое новое и интересное из мира Вордпресс в моём Телеграм-канале . Подписываемся!