Как я могу найти слаг плагинов?


11

Мне интересно, как я могу найти слаг плагинов (slug = внутреннее имя, используемое WordPress для обновления плагинов и определения, какие плагины активны в настоящее время)? Обычно это имя папки плагина, но если у плагина нет папки, это имя файла (например, hello.php). Есть ли другие исключения?

  1. Имеют ли значение строчные и прописные буквы?
  2. Может ли плагин иметь другой слаг, чем имя его папки? Что если есть плагин с именем hello.php и другой /hello.php/hello.php?

Очень хороший вопрос, жаль, что мы не можем присудить награды Q, но я думаю, что A - это награда;)
brasofilo

Ответы:


8

Строка, используемая в WordPress для идентификации плагина:

plugin_basename($file);

... где $fileэто файл с заголовками плагинов .

Так что, если вы в своем плагине, получите слаг с:

$slug = plugin_basename( __FILE__ );

1
plugin_basename ($ файла); Не является слизняком с 3.8.1. Это путь к папке / plugin_main_file.php. В качестве «слаг» плагина Akismet - это не «akismet / akismet.php», а «akismet».
Джефф Мэттсон,

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

@ majick true, для Wordpress 4.7.4 это не ответ
Marecky

2
Другой способ создать слаг плагина - использовать dirname(plugin_basename(__FILE__)).
Иланко

2

Если вы устанавливаете WP-CLI, вы можете получить список плагинов с их слагом и версией из командной строки:

> wp plugin list

Я знаю, что это, вероятно, не то, что вы хотите, если вам нужно найти слаг в коде, но это помогло мне при работе с плагином TGM-Plugin-Activation.

Мне трудно работать с WordPress без WP-CLI, в общем, это очень полезный инструмент для многих общих задач, связанных с WordPress.


2

Разница между файлом плагина (основным) и слагом плагина - это место, где Кодекс 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 () ) и получить оттуда файл плагина.

Если вы знаете класс или функцию, определенную этим плагином, вы можете использовать отражение (см. Этот ответ для классов и этот для функций).


Я надеюсь, что это поможет вам и другим людям, которые могут испытывать трудности при работе с "плагинами плагинов". Это могло бы сэкономить мне пару часов :)


0

Просто чтобы уточнить, так как оригинальный пост.

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

Например, если я обнаружил приведенный ниже код в файле с именем advanced-plugin-awesomeness.php, мой слаг будет расширенным-plugin-awesomeness.

Надеюсь это поможет!

/*
Plugin Name: Name of plugin here
Version: 2.4.6
Description: plugin description here
Author: plugin author here

-1, поскольку большинство имен файлов и каталогов совпадают, это ненадежный метод, поскольку слаг обновления - это фактически каталог, а не имя файла (если только нет каталога.)
majick

или даже не каталог! см. мой обновленный ответ, это на самом деле происходит от имени плагина.
Маджик

0

К сожалению, слаг возвращается через API обновлений, ответ на этот вопрос не так очевиден, если вы не запросите сам API. Однако, если вы хотите увидеть список текущих слагов плагинов и связанных с ними данных плагинов, вы можете просто сделать:

print_r(get_site_transient('update_plugins'));

Но, это не будет иметь информацию о недавно установленном плагине в течение еще 12 часов, вам придется сделать что-то другое для них, например. использовать модифицированную версию кода из wp_update_pluginsв wp-includes/update.php...

Сделав это, чтобы проверить это, кажется, подтверждает, что, независимо от имени файла плагина или местоположения или заглавных букв, именно он Plugin Nameгенерирует слаг обновления, скорее всего, через sanitize_title. Поэтому я считаю, что правильный ответ должен быть:

// if you have the plugin basename:
// $pluginfile = WP_PLUGIN_DIR.'/'.$pluginbasename;

// otherwise if you have the absolute path already:
$plugin = get_plugin_data($pluginfile);
$pluginslug = sanitize_title($plugin['Name']);

+1, и еще одно замечание: со временем это может измениться, так как команда wordpress.org прямо указала на то, что методология расчета слагов еще не окончательно
Марк Каплун

Я не уверен, что это точно, я пытался сделать это для плагина, но это не удалось: имя плагина в ответ возвращается «Отзывчивый слайдер WordPress - Soliloquy Lite», а слаг: soliloquy-lite
Chris

Я подозреваю, что это потому, что слаг генерируется в то время, когда плагин передается в хранилище и не меняется с именем позже ... в большинстве случаев он совпадает с именем каталога, но если есть исключения для обоих, он может быть тем или другим. это не идеально: - /
Маджик

0

Вы можете получить имя папки плагина (PHP5.3 +), передав DIR в plugin_basename (), например так:

$plugin_foldername = plugin_basename( __DIR__ );

0

Попробуй это:

function get_slugname(){
    $tmp = array();
    $plugins_all = get_plugins() ;
    $plugin_slug = explode('/',dirname(plugin_basename(__FILE__)));
    foreach ($plugins_all as $key=>$value) {
        if ($plugin_slug[0] == explode('/',$key)[0] ) {
        $tmp = $value;
        $tmp['slug'] = explode('/',$key)[0];
        $tmp['file'] = explode('/',$key)[1];
        }
    }
return $tmp;
}

1
Пожалуйста, измените свой ответ и добавьте объяснение того, что делает этот код.
Натан Джонсон

0

Для большинства плагинов «slug» будет таким же, как имя каталога. Хотя .org люди могут установить имя каталога на что угодно.

$slug = (dirname(plugin_basename(__FILE__)));
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.