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

Ничего не произойдёт.
Просто будет чуть-чуть медленнее работать из-за необходимости преобразовать все GET/POST переменные (убрать последствия работы MagicQuotes'а).

Хм.. действительно интересный вопрос получается.
Если надо только на главной такое сделать - можно направлять просто на "/", а вот если подобный фильтр нужно делать для любых новостей, то без плагина-фильтра не обойтись, нужно будет цепляться на событие onBeforeShow

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

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

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

exec_acts('super_action');

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

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

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

Лучше делать отдельным плагином.
Сейчас же, как минимум, появляется уязвимость с возможностью исполнения произвольного PHP кода.

Если автор гостевой книги не озаботился о таком виде защиты, то любой желающий сможет исполнить любой код на твоём сайте,... согласись - это не очень хорошо..

Если нет категории, то двиг использует "none" вместо альт. имени категории.
А вообще двигу пофигу на категорию - уникальным идентификатором новость является её альт. имя

Убрать можно всё, вопрос в другом - надо ли оно тебе?

p.s. Видимо ты про другое хочешь спросить? Как теперь находить новости, которые отмечены как "отобразить на главной"? Заходишь... правильно - в "управление форматом ссылок", находишь news:main ("Главная новостная страница") и прописываешь желаемый URL

Уже кому-то отвечал, а потом в SVN версии добавил маленький хак для удобства.

Открываешь index.php, находишь:

// /////////////////////////////////////////////////////////// //
// You may modify variable $systemAccessURL here (for hacks)   //
// /////////////////////////////////////////////////////////// //


// /////////////////////////////////////////////////////////// //

Вставляешь в середину:

if (($systemAccessURL == '/')&&($_SERVER['REQUEST_METHOD'] == 'GET')) {
 $systemAccessURL = '/static/15.html'; // вставляешь адрес твоей статик страницы
}

Что за плагин делаешь?

Выложил драфт описание структуры файла version, пока ещё не интегрированное в основное меню документации.
Если найдёшь какие-либо неточности - пиши.

Чуть позже дам и описание существующих action'ов и правила их использования.

"Глубоко встроенных" (типа magic quotes) функций нет - если серьёзно, но от подобных вещей вреда больше чем пользы.

В самом же движке (и во всех плагинах) используется стандартный метод - без экранирования в SQL запрос добавляются только те переменные, которые сформированы двигом (к примеру, собственный счетчик) и в которых не может быть ничего опасного.

Для экранирования используется функция db_squote(), рекомендую использовать именно её (она находится в functions.inc.php и сама добавляет апострофы). Если посмотришь на SQL запросы, то заметишь, что она используется в 90% запросов

Логичнее было бы это захардкодить. Так, наверное, и сделаю - категории с альт. урлом не предназначены ведь для использования в новостях.

Styler, плагин адаптировать под новую версию будешь?

Настройки хранятся не в БД, а в файлах в engine/conf/
Полный бекап БД и есть бекап пользователей + новостей + данных плагинов (к примеру, тегов плагина tags для новостей).
Просто бекапить/восстанавливать отдельно пользователей (или новости или ещё что) нельзя - поплывут нафиг все связи автор<->контент