Разница между файлом плагина (основным) и слагом плагина - это место, где Кодекс WordPress мог бы работать намного лучше. Я понимаю ваше замешательство, поскольку я чувствовал это слишком недавно (смешанный с разочарованием).
Это то, чему я научился, выполняя «детективную работу» над кодом ядра WordPress.
Файл плагина
Это уникальный способ, которым WordPress идентифицирует и записывает плагин. Он состоит из каталога плагина и основного файла плагина (файл с заголовком файла, содержащим различные данные плагина, такие как версия, автор и т. Д.).
Это будет выглядеть примерно так: your-plugin-directory/main-file.php
Если вы посмотрите на данные активных плагинов (возвращаемые get_option( 'active_plugins' )
), то увидите, что WordPress нужен только этот файл плагинов для правильной идентификации плагинов.
Вы можете думать об этом как об относительном пути основного файла вашего плагина (относительно wp-content/plugins/
каталога, который есть). Вы можете «составить» абсолютный путь к основному файлу плагина примерно так:trailingslashit( WP_PLUGIN_DIR ) . $plugin_main_file
Само ядро генерирует файл плагина следующим образом:
$plugin_main_file = plugin_basename( trim( $plugin_main_file_absolute_path ) );
Плагин слизняк
Можно было бы ожидать, что плагин "slug" будет своего рода стандартизированным идентификатором для плагина, как post-slug для постов - так что вы можете использовать этот "slug", чтобы предоставить его основным функциям WordPress и добиться успеха.
На самом деле, нет. После поиска в ядре ссылок на слагы плагинов (или тем, которые имеют значение) и почти ничего не нашли, я думаю, что у меня есть понимание.
Единственные настоящие слагы - это те, которые доступны через уникальный URL-адрес: посты, страницы, таксономии и т. Д. В этом и заключается смысл взять название чего-либо (например, заголовок поста) и создать URL-версию, подходящую для URL: использовать это в URL.
Но где мы используем тему / плагины "слагы" в URL?
Мы не делаем этого на отдельных установках WordPress - ни в админке WP, ни во внешнем интерфейсе.
Тем не менее, есть место, очень запутанное с кодом WordPress, сайт WordPress.org. Людям трудно различать их, в том числе то, что разработчики как-то часто считают, что тема WordPress или слагы плагинов должны работать так же, как пост-слаг или пост-слаг.
Они служат той же цели, но на разных сайтах. На WordPress.org они используются для уникальной идентификации темы от других и плагина от остальных (в URL-адресах, как https://wordpress.org/plugins/akismet/
).
Но когда дело доходит до отдельных установок WordPress, та же уникальность не может быть гарантирована, потому что нет полномочий для ее принудительного применения (как на WordPress.org). Это могло бы работать, если бы все плагины и темы были взяты с WordPress.org, но, к счастью, это не так.
Что делает код WordPress со слагами темы / плагина?
Код ядра WordPress не использует слагов тем / плагинов для таких вещей, как установка, активация, обновление, удаление тем или плагинов.
Для тем он опирается на каталог тем, поскольку основной точкой входа в тему является style.css
файл (вы не можете использовать другой файл CSS для хранения заголовка сведений о вашей теме).
Для плагинов он опирается на каталог плагинов И основной файл плагинов, поскольку плагины могут вызывать свои основные файлы так, как им нравится.
Единственное, для чего ядро использует слагы theme / plugins - это когда оно обрабатывает темы и плагины из каталога WordPress.org: выборка списков плагинов, проверка обновлений, отправка отчетов по данным об использовании каталога и т. Д.
Чтобы подвести итоги о подключаемых модулях плагинов: всякий раз, когда вы обнаруживаете данные подключаемых модулей с slug
записью, в 99% случаев они ссылаются на слаг WordPress.org.
Как мы можем определить плагины?
Если вы хотите программно активировать, обновить, деактивировать или удалить определенный плагин при установке WordPress, вам необходимо использовать файл плагина. Вы можете получить это так из основного файла вашего плагина:
$plugin_file = plugin_basename( __FILE__ );
Если вы хотите настроить таргетинг на определенный плагин из другого плагина, все станет немного сложнее, поскольку вам нужно полагаться на «догадки».
Вы можете жестко закодировать имя плагина, выполнить поиск плагина в списке всех плагинов (см. Get_plugins () ) и получить оттуда файл плагина.
Если вы знаете класс или функцию, определенную этим плагином, вы можете использовать отражение (см. Этот ответ для классов и этот для функций).
Я надеюсь, что это поможет вам и другим людям, которые могут испытывать трудности при работе с "плагинами плагинов". Это могло бы сэкономить мне пару часов :)