Сервисные функции при создании плагинов

vitaly · 2009-09-24 19:25:10

Описание action'ов будет сегодня-завтра - мне осталось ещё немного с документацией по шаблонам, сразу после этого займусь описанием плагинов и начну с action'ов.

Создание своих собственных action'ов обычным плагинам действительно крайне нежелательно.
Но вот если речь идёт про какие плагины-enabler'ы (обеспечивающие работу других плагинов) или наоборот про плагины-агрегаторы (для работы которых создаются дополнительные плагины), то создание собственных action'ов - правильный путь.
Сейчас таких плагинов всего 2: comments (исторически сложилось + позволяет работать плагинам, фильтрующим комментарии) и finance.

Создать action не просто, а безумно просто. Пишешь в коде:

exec_acts('super_action');

и можешь смело указывать этот самый action в файле version других плагинов. Логику действительно проще всего посмотреть в дебаге - становится всё значительно понятней.

Оповещение должно работать через сайт с опубликованными плагинами, но сейчас живёт на ручнике: при заходе на страничку плагина двиг с определённой периодичностью делает запрос на ngcms.ru, сообщает список установленных у себя плагинов и их версии и в ответ - получает список плагинов по которым доступны новые версии + ссылки на страницы плагинов.

p.s. ob_clean не используется, поэтому для debug'а можно использовать обычные print'ы (я, кстати, именно так при отладке и поступаю)

Amarelius · 2009-09-27 18:55:42

vitaly, чисто для спортивного интереса сделал следующее

ini_set("display_errors","1");
if (version_compare(phpversion(), "5.0.0", ">")==1) {
	ini_set("error_reporting", E_ALL | E_STRICT);
} else {
	ini_set("error_reporting", E_ALL);
}

.... и вылезло немного мусора, все по мелочам.
Планируешь подчищать?

vitaly · 2009-09-27 23:55:14

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

Кое что, думаю, устраню, но специально вычищать все эти сообщения не вижу смысла.
Когда мне надо проверить условие "элемент массива определён и её значение не равно нулю (фактически - установлено в единицу)" я пишу:

 if ($params['var']) {;}

при этом чтобы не получать Warning'ов надо писать:

 if (isset($params['var']) && $params['var']) {;}

что фактически не даёт никакой пользы.

p.s. Если обоснуешь причину, по которой это надо вычищать - вычищу.

vitaly · 2009-09-28 02:17:24

Подумал,... ещё раз подумал,.. и понял, что вычищать всё-таки надо и буду (и даже уже начал).
Но твои аргументы услышать всё-равно хотелось бы

Amarelius · 2009-09-28 11:47:11

Да принципе вылезли там только не инициализированные переменные, индексы массивов и не установленные временные зоны, и если грамотно использовать isset в конструкциях if, то проблем от них вообще нет, а если где и пропустить isset, то в режиме ^ E_NOTICE ей будет присвоен null, а интерпретатор даже не пискнет, просто где-то пользователь увидит информацию (например из базы), которую он не хочет или не должен видеть, а с учетом того что в большинстве случаев индексы начинаются с 1(в базах данных), то вообще ничего не увидит или не изменит (чисто гипотетически). Больше пользы от такого режима (для себя) вижу при написании плагинов, просто совершаешь меньше детских ошибок, и не тратишь по пол дня на их поиск.

А с датами все еще проще, надо установить временную зону по умолчанию date_default_timezone_set и все. К чему приведет ее не установка? Просто в функциях работы с датами временной зоной по умолчанию будет установлена временная зона сервера.

Изменено Amarelius (2009-09-28 11:50:06)

vitaly · 2009-09-28 11:54:39

Amarelius, собственно isset'ами всё и проверяю. Уже нашел один ставший ненужным кусок кода и придумал что делать с потерянными LANG переменными (можно вместо них выводить отдельное сообщение при отладке).
Кстати, сейчас в SVN версии такие ошибки ещё, конечно, остались, но их стало в десятки (если не сотни) раз меньше.

С default timezone так и поступил. Но лично мне вариант, предложенный разработчиками PHP очень не понравился - нельзя указать "TZ = +0300", можно только "TZ = Europe/Moscow" и вынести в конфиг движка тот огромный список вариантов записей TimeZone не получится

Amarelius · 2009-09-28 12:07:19

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

Изменено Amarelius (2009-09-28 12:12:10)

vitaly · 2009-09-28 18:20:53

О, не подумал.
Спасибо за наводку, в будущем реализую.

Вот только не очень понятно - что это за класс такой и у всех ли он установлен.

Amarelius · 2009-10-12 19:30:22

vitaly, а есть функция которая удаляет кеш определенных страниц у определенных плагинов?
Не смог найти...

Изменено Amarelius (2009-10-12 19:31:23)

insider · 2009-10-12 21:05:26

Функции нет, но можешь использовать подобную строку:

@unlink(get_plugcache_dir('id_плагина') . $cacheFileName);

Или более полный вариант на примере плагина календаря:

@unlink(get_plugcache_dir('calendar') . md5('calendar'.$config['theme'].$config['default_lang'].$year.$month).'.txt');

Вместо $config['theme'] можешь подставить id темы, для которой надо удалить кэш, вместо $config['default_lang'] - язык, $year и $month - год и месяц соответственно.
Например, чтобы удалить кэш календаря за октябрь 2010 для default темы и текущего языка по умолчанию:

@unlink(get_plugcache_dir('calendar') . md5('calendardefault' . $config['default_lang'] . '201010').'.txt');

Amarelius · 2009-10-19 13:26:15

На будущее.
Не плохо бы модифицировать class tpl таким образом, чтобы он позволял задавать глобальные значения переменных, которые действовали бы во всех шаблонах.

Amarelius · 2009-10-29 14:43:06

vitaly или ROZARD, проконсультируйте меня по поводу $CurrentHandler, что это вообще за зверь и какая у него структура, не до конца его понял.

vitaly · 2009-10-29 18:03:54

$CurrentHandler - глобальный массив в котором сохраняется информация о результате анализа URL'а по которому зашел пользователь.
Данный массив заполняется значениями уже после того, как отрабатывают action'ы:
* auth
* core
* index_pre

Т.е. в action'ах:
* index
* maintenance
* ppages
* news / comments (и все их подвиды)
значение этого массива заполнено корректно.

Содержимое массива:

array(
'pluginName' => $pluginName - ID плагина к которому обращаемся
'handlerName' => $handlerName - обработчик к которому обращаемся
'params' => $params - доп. параметры; их набор можно посмотреть в настройках ЧПУ. для каждого типа URL'а их набор бывает разным
)

Для отладки можно открыть index.php (строка ~87):

$runResult = $UHANDLER->run($systemAccessURL, false);

и заменить false на true - начнёт валиться куча debug информации от обработчика ЧПУ, в самом конце он отдаст список полученных переменных.

Amarelius · 2009-10-31 15:08:03

При использовании $ULIB->removeCommand
Данные из rewrite.php не удаляются.

И еще, я считаю что файлы rewrite.php и urlconf.php не должны идти в дистрибутиве движка, а должны формироваться при установке.

vitaly · 2009-10-31 16:41:14

Amarelius, а после removeCommand() ты вызываешь saveConfig()?

И еще, я считаю что файлы rewrite.php и urlconf.php не должны идти в дистрибутиве движка, а должны формироваться при установке.

А смысл?

Amarelius · 2009-10-31 17:07:55

vitaly пишет:

...а после removeCommand() ты вызываешь saveConfig()?

Обязательно

function plugin_aa_rating_install($action) {

	$ULIB = new urlLibrary();
	$ULIB->loadConfig();
	$ULIB->removeCommand('aa_rating', '');

	switch ($action) {
		case 'confirm': generate_install_page('aa_rating', 'Cейчас плагин будет удален', 'deinstall'); break;
		case 'autoapply':
		case 'apply':
			$ULIB->saveConfig();
			plugin_mark_deinstalled('aa_rating');
			break;
	}
	return true;
}

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

--------------------------------------------------------------------------------

vitaly пишет:

А смысл?

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

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

vitaly · 2009-10-31 21:18:18

Amarelius, а можешь сразу после строки

$ULIB->saveConfig();

добавить что-то типа

print "Изменены настройки ULib";

и удостовериться, что сообщение действительно выводится? Тогда займусь

Amarelius · 2009-10-31 21:57:44

vitaly, сделал, вот результат

Удаляем

Подтверждаем

vitaly · 2009-10-31 22:13:50

Погоди, только что понял.
removeCommand() удаляет комманду из списка доступных комманд, но не удаляет её при этом из списка ЧПУ URL'ов.

Amarelius · 2010-01-11 18:08:14

vitaly, при изменении версии некоторого плагина есть необходимость запуска скрипта на обновление структуры БД. Хотелось бы сделать вызов этого скрипта автоматическим.

Например можно хранить версии всех плагинов в папке с настройками движка, а в функции repoSync() проверять совпадают ли эти версии с реальными для плагинов (из переменной $extras) и если не совпадают и при прописанном upgrade в version для соответствующего плагина (забыл сказать что необходимо будет добавить параметр типа upgrade в файл version который будет равен имени скрипта с обновлением) отображать рядом с именем плагина иконку символизирующую о необходимости вызвать скрипт обновления для данного плагина при клике на которую он собственно и будет вызван.

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

vitaly · 2010-01-12 00:01:05

Идея ясна, занесу в TODO list (в голове который)

Amarelius · 2010-01-12 15:41:27

vitaly, думаю в функцию fixdb_plugin_install стоит добавить флаг игнорирования ошибок.

Next Generation CMS :: Форум поддержки

Объявление

#26 2009-09-24 19:25:10

Re: Сервисные функции при создании плагинов

#27 2009-09-27 18:55:42

Re: Сервисные функции при создании плагинов

#28 2009-09-27 23:55:14

Re: Сервисные функции при создании плагинов

#29 2009-09-28 02:17:24

Re: Сервисные функции при создании плагинов

#30 2009-09-28 11:47:11

Re: Сервисные функции при создании плагинов

#31 2009-09-28 11:54:39

Re: Сервисные функции при создании плагинов

#32 2009-09-28 12:07:19

Re: Сервисные функции при создании плагинов

#33 2009-09-28 18:20:53

Re: Сервисные функции при создании плагинов

#34 2009-10-12 19:30:22

Re: Сервисные функции при создании плагинов

#35 2009-10-12 21:05:26

Re: Сервисные функции при создании плагинов

#36 2009-10-19 13:26:15

Re: Сервисные функции при создании плагинов

#37 2009-10-29 14:43:06

Re: Сервисные функции при создании плагинов

#38 2009-10-29 18:03:54

Re: Сервисные функции при создании плагинов

#39 2009-10-31 15:08:03

Re: Сервисные функции при создании плагинов

#40 2009-10-31 16:41:14

Re: Сервисные функции при создании плагинов

#41 2009-10-31 17:07:55

Re: Сервисные функции при создании плагинов

#42 2009-10-31 21:18:18

Re: Сервисные функции при создании плагинов

#43 2009-10-31 21:57:44

Re: Сервисные функции при создании плагинов

#44 2009-10-31 22:13:50

Re: Сервисные функции при создании плагинов

#45 2010-01-11 18:08:14

Re: Сервисные функции при создании плагинов

#46 2010-01-12 00:01:05

Re: Сервисные функции при создании плагинов

#47 2010-01-12 15:41:27

Re: Сервисные функции при создании плагинов

Подвал раздела