Чтобы в дальнейшем наши англоговорящие дружбаны могли перевести скрипт на свой язык была сделана функция t() в которую помещается текст:
<?=t('Тутачки мы пишем какие-то очень умные и совсем непохабные слова.'); ?>
По всему скрипту разбросаны фильтры и экшены. Создать свой фильтр (в плагине, например) можно так:
$var = run_filters('filter-name', $var);
Как можно заметить, тут переменная $var пропускается через фильтр filter-name. Действие для этого фильтрп в плагине будет выглядеть так:
add_filter('filter-name', 'function_name');
function functionname($param1 [, $param2]){
return $param1;
}
$param1 это $var, который мы через фильтр пропускаем. $param2 это имя фильтра, то есть, в примере filter-name (обратите внимание, пробел нужно заменять знаком минуса, так уж пошло). Делать return для $param1 обязательно, иначе всё пропадёт, точнее, содержание $var пропадёт.
Для экшенов ещё проще:
$var = 'что-то очень интересное';
run_actions('action-name');
В плагине вызывать так:
add_filter('action-name', 'function_name');
function function_name([$param]){
global $var;
}
$param в экшене это его имя, в примере - action-name.
Ещё есть маленькая тонкость.
add_filter(string filter_name, string function_name[ , int приоритет]);
add_action(string action_name, string function_name[ , int приоритет]);
Первые два параметра понятны, мы их чуть выше разобрали. А вот третий, необязательный, это приоритет фильтра или экшена. По умолчанию он равен 50.
После того, как мы решили сделать плагин (об этом чуть ниже) нужно найти нужный фильтр или экшен. Честно говоря, это самый сложный из этапов.
Итак, цель: заменить тег {ip} в комментарии на IP комментатора. Логично предположить, что искомый фильтр или экшен находится в файле отвечающем за вывод комментариев. Где же он прячется, этот фаил? В папке inc - фаил show.comments.php. Открываем его, пробегаемся глазами и видим:
$output = run_filters('news-comment', $output);
Мы нашли. Мы мо-ло-дцы. Дело за малым, написать нужную функцию.
add_filter('news-comment', 'function_name');
function function_name($param1){
global $row;
$param1 = str_replace('{ip}', $row['ip'], $param1);
return $param1;
}
Всё. Плагин написан.
Теперь нужно плагину дать имя и описание. По большому счёту, это просто. Есть общий шаблон:
/*
Plugin Name: Название плагина
Plugin URI: Ссылка на плагин
Description: Описание плагина
Version: Версия плагина
Application: Программа
Author: Имя автора
Author URI: Ссылка на хомпейдж автора
*/
"Название плагина"* должно быть всегда по-английски, если это не плагин Ago или Кавычкер - они оба ориентированны на русский язык, имя их может быть и по-русски, англоговорящим такой плагин и не нужен вовсе.
"Ссылка на плагин" это, обычно, УРЛ нашего сайта, потому что там можно будет скачать его, плагина, новую версию: http//cutenews.ru
"Описание плагина"* должно выглядеть так: Описание по-русски<br /><br />Описание по-английски. То есть сверху по-русски, чуть ниже по-английски. Опять же, если это не чётко русский плагин, такой как Кавычкер.
"Версия плагина" вообщем-то версия плагина. Например: 1.0. Что ещё сказать? :)
"Программа"* либо CuteNews, либо Strawberry. Одно на другом работать не будет. Когда имя программы не совпадает с именем текущей программы, то в списке такой плагин не появится. Если его каким-то чудом активировать, то он всё равно будет дезактивирован скриптом.
"Имя автора" имя автора плагина.
"Ссылка на хомпейдж автора" это обычный УРЛ к домстранице.
* обязательно нужно указывать:
/*
Plugin Name: Название плагина
Description: Описание плагина
Application: Программа
*/
Так как в итоге мне этот плагин смотреть, то уж извините, есть следующие требования.
Первое. Всегда делать вот такой комментарий, если нет внешних функция (например, как у плагина Custom Quick Tags):
/**
* @package Plugins
* @access private
*/
Если внешнии (которая будет вызываться за пределами плагина) функции имеются (как у CN Functions), то должно быть так:
/**
* @package Plugins
*/
И каждой функции в этом случае нужно давать комментарий. На примере CN Functions cn_calendar() (вневшняя функция):
/**
* @return string Таблицу месяца, в которой где $year это год, $month - месяц, $day - день
*/
function cn_calendar(){
global $cache, $year, $month, $day, $PHP_SELF, $sql, $config;
и count_month_entry() (рабочая функция в данном плагине):
/**
* @access private
*/
function count_month_entry($date){
global $sql;
count_month_entry() не попадёт в описание функций, а cn_calendar() попадёт.
Второе. Вы можете писать плагин так, как угодно вашей душе (я всё равно потом запущу phpCodeBeautifier), за исключением только двух деталей - кавычек и функции echo() (кавычки всегда должны быть одинарными (хз, как называются)('):
$var = 'khjkhjkjh \' jghjghj';
Теперь про echo(). Лучше использовать именно её. По религиозным соображениям.
echo 'что-то';
Или:
echo $var;
Если текста для вывода много, то лучше не писать:
echo 'куча текста';
А писать:
?>
куча текста
<?
И короткии теги я люблю:
<?=$var; ?>
А не:
<?php echo $var; ?>
Это не очень правильно, но хостинги без коротких тегов я не встречал ещё, да и считайте короткие теги одним из требований скрипта.
if..else и причие операторы нужно оборачивать {} всегда, даже если код в них состоит из одной строчки.
Просто мне смотреть плагин, мне его читать и в дальнейшем мне с ним работать. Если в echo будет 20 килобайт текста, то плагин может быть самым гениальнейшим, работоспособнейшим, но я его читать не буду. И в дистрибутив он 100% не войдёт.
Комментарии вроде
/**
* @access private
*/
Мне не особо нужны. Больше они нужны PhpDocumentor`у, который на много-много часов быстрее. чем я составит описание функций.
Плагин всегда должен начинаться с:
/**
* @package Plugins
* @access не писать или private об этом я выше писал
*/
Дополнение (типа поиска или rss) с:
/**
* @package Show
* @access не писать или private об этом я выше писал
*/
То что написано выше обязательно. И обязательно сверху файла.
Все рабочии функции должны быть private:
/**
* @access private
*/
Чтобы не было по ним описания, ибо если плагина нет или выключен, то будет кирдык.
Для функций синтаксис комментариевтакой:
/**
* Описание
* @param тип $var Описание
* @return тип
*/
"описание" не обязательно, ни для функции, ни для параметра
"тип" это string (строка), int (число), void (пусто), mixed (что угодно), bool (1/0 или true/false) или array (массив). Надеюсь, ничего не пропустил.
На примере функции:
/**
* @param string $param1
* @param int $param2
* @return string
*/
function foo($param1 = 'значение', $param2 = 2){
return $param1;
}
Напомню, описание каждой функции нужно только, если @access public, если @access private ничего описывать не нужно. Всё по умолчанию описывааться не будет.
Для закрепления :), я приведу код написаного нами плагина уже в готовом виде. Итак, сначала с @access private (за английское описание вы меня простите поалуйста, не знаю я этого варварского языка):
/**
* @package Plugins
* @access private
*/
/*
Plugin Name: IP in Comments
Description: Заменяет {ip} на IP комментатора<br /><br />Replace {ip}to commentator`s IP
Application: Программа
*/
add_filter('news-comment', 'function_name');
function functionname($param1){
global $row
$param1 = str_replace('{ip}', $row['ip'], $param1);
return $param1;
}
Тоже самое только с @access public:
/**
* @package Plugins
*/
/*
Plugin Name: IP in Comments
Description: Заменяет {ip} на IP комментатора<br /><br />Replace {ip}to commentator`s IP
Application: Программа
*/
add_filter('news-comment', 'function_name');
/**
* @access private
*/
function functionname($param1){
global $row
$param1 = str_replace('{ip}', $row['ip'], $param1);
return $param1;
}