Одна из моих тем Wordpress требует нескольких сторонних плагинов для правильной работы.
В большинстве случаев я использовал для вызова функций из сторонних плагинов, используя условные операторы, такие как
if(function_exist('plugin_function')) {
plugin_function() // do something
}
Предположим, хотя мне нужно широко использовать один плагин во многих файлах моей темы ... Я бы хотел избежать использования многих условий IF ... Есть ли правильный способ требовать установки определенного определенного плагина в WP или, что еще лучше, установить их? если они отсутствуют до активации темы?
Спасибо
источник
function_exists
, то обычный пользователь просто получит сообщение, что он не установил плагин, на который полагается другой плагин. Проблема заключается в том , что пользователь действительно будет установлен плагин , а затем просто интересно , почему это doens't работы . О, и я не собираюсь понижать тебя за это.Хотя это не помешало бы нарушить тему, когда плагин отключен, я бы посмотрел эту замечательную статью о плагине «Как отобразить уведомление администратора для необходимых тем» . Меня никогда не устраивала идея, заставляющая плагин быть установленным, и поэтому это кажется следующим лучшим вариантом.
Еще одна быстрая мысль: я никогда не пробовал этого, но мне интересно, не могли бы вы придумать какой-нибудь умный способ разместить несколько хуков в одном условии. Возможно, вы могли бы выделить все условные функции в другом файле и требовать его только при
if( function_exists( 'plugin_function' ) )
возвратеtrue
(при том понимании, что это несовершенная проверка.источник
Если вам нужна только плагинная страница, то есть
is_plugin_active()
. Если вам это нужно снаружи, лучше скопируйте / вставьте базовую функцию в вашу тему, а затем снова используйте ее:Условное исключает любые ошибки с двойным определением функции.
источник
if(function_exist('plugin_function'))
наif(is_plugin_active('plugin-file.php'))
Примечание. Этот ответ только для того, чтобы облегчить обсуждение между @scribu и @kaiser. Моды: пожалуйста, не удаляйте. Пользователи / Читатели: Пожалуйста, не голосуйте. Если вы хотите следить за обсуждением, посмотрите журнал изменений / редактирования. Если вы хотите присоединиться к обсуждению, отредактируйте ответ. Если обсуждение имеет результат, то оно будет помечено как таковое. Спасибо.
Сценарии
Существуют также разные сценарии, которые имеют разный вес, где вы можете иметь зависимость от плагина. (Примеры только вымышленные). Слово «(родительский) плагин» можно заменить на «тему» с родительской точки зрения.
Далее я попытаюсь набросать, что происходит, когда вы обновляете «другой» плагин и проверка больше не работает.
Проверьте
Есть три возможности проверить, если вы хотите знать, активен ли плагин:
'active_plugins'
- существует?Если я сейчас возьму свой плагин Internal Link Checker в качестве примера, который не предлагает общедоступный API и не предназначен для расширения, то я бы не увидел причин (как автора) не изменять именование внутренних функций по требованию или только по желанию , Так что, если кто-то попытается использовать этот плагин, он просто сломается (в зависимости от функциональности и жесткости комплектации) при обновлении. То же самое касается имен файлов. У меня не было бы реальной причины (кроме того, что плагин будет деактивирован при обновлении), чтобы не изменять имя файла. Единственное, что могло бы удержать меня от изменения имени папки, - это то, что проверка обновлений и уведомление выполняются для имени файла - если оно размещено в официальном репозитории.
Поэтому я бы сказал, что от самой слабой (легко изменяемой) до самой жесткой (много говорят против изменения) части (родительского) плагина будет:
функция »имя основного файла» папка
Когда я сказал, что проверка функции менее хрупкая, чем использование,
is_plugin_active()
я предположил, что рассматриваемая функция - это та, которую явно поддерживает автор плагина. Конечным примером этого будетwp_pagenavi()
тег шаблона, предлагаемый плагином WP-PageNavi.Сложность в определении зависимостей заключается в том, что не существует стандартного способа уникальной идентификации плагинов, который не включает имена файлов.
Больше мыслей на эту тему:
http://wordpress.org/support/topic/plugin-plugin-dependencies-unreliable-plugin-namingidentifying-scheme
Я думаю, мы можем подвести итог в трех пунктах:
(Пока) самый умный способ, который я могу придумать, который я уже видел в некоторых (слишком много) плагинах:
Не думая слишком подробно об этом, но я думаю, вы могли бы подключить свое уведомление к проверке «все» фильтра и проверить внутри текущего фильтра, если он был запущен, когда вы находитесь на
shutdown
крючке ...?@scibu Это было нацелено на "вашу" тему. (Я уже бросил говорить о моем). :)
Так что, в принципе, если вам нужна зависимость - и у вас есть хороший автор - тогда он может предложить вместо этого хук в качестве замены тега шаблона. Потому что плагин будет подключаться к нему только в том случае, если он будет присутствовать или просто ничего не делать. А с другой стороны у вас не будет ошибки, когда плагины отсутствуют.
Вот трудная часть (или более Q): Чтобы написать уведомление администратора для информирования пользователя о зависимости «Вам нужно установить» DisneyWonderLinks «», вы можете проверить
array_keys( $GLOBALS['wp_filter']['template_tag_like_hook'] )
. Я не уверен, что это будет работать, но на самом деле массив должен быть доступен с обеих сторон (public / admin).Это не сработает. Тот факт, что обратный вызов зарегистрирован для ловушки, не означает, что ловушка будет срабатывать, когда ожидается. Единственная вещь, которая могла бы работать подобным образом, - это использовать хук 'shutdown', о котором вы упоминали ранее:
Конечно, это будет напечатано в самом низу, после
</html>
тега, во внешнем интерфейсе (поскольку там обычно используются теги шаблонов), что не очень полезно.Вы можете попытаться сохранить сообщение в wp_options, а затем отобразить его в административной области, но это откроет совершенно новую банку червей: аннулирование, плагины для кэширования и т. Д.
источник