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

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

СИСТЕМНЫЕ ТРЕБОВАНИЯ
----------------------------
- Apache 1.x/2.x
- PHP 4.3.x
- MySQL 4.x/5.x

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

По идее (но не обязательно) у тебя в панели управления хоста должна быть утилитка phpMyAdmin, так вот, заходишь в нее и там будет кнопочка (или ссылочка) "Выполнить запрос", щелкаешь, в большое текстовое поле вводишь что-то типа SELECT DAYOFMONTH(from_unixtime(postdate)) as day, count(id) as count FROM ng_news жмешь "Выполнить" и смотришь результат, если не матюкнулось и корректно обработало (а если матюкнется ты это сразу поймешь), то все ОК и ты можешь потихоньку начинать перелопачивать движек заменяя DAY на DAYOFMONTH

версия sql какая?
скорее всего твоя версия не поддерживает такую форму запроса
-----------------------------------------------
Только что глянул, так и есть, если у тебя версия сервера 4.0, то функция DAY() у тебя работать не будет. Она появилась только в v4.1.1
-----------------------------------------------
Еще раз глянул, можно заменить функцией DAYOFMONTH()

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

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);
}

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

ROZARD, еще раз спс., ссылку я уже обнаружил.
По твоему совету включил debug (как я сразу не догадался? наверно прогулял этот урок в школе) и с action стало все понятно.

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

Когда придет время использовать свои action, думаю разберусь, а вот за debug-режим действительно спасибо, просто как-то вылетело из головы.
Кстати, я для вывода значений php-функции var_dump использую функцию движка msg, ты знаешь как можно использовать var_dump более корректно, а то как то некошерно получается, или как вывести значения интересующих меня переменных в debug-блок.

Замечание к 378- ревизии. Все-таки неплохо было-бы описать action-ы для полноты понимания работы ядра. Например мне не очень понятно при каких условиях тот или иной плагин привязывать к тому или иному action-у. Ведь в большинстве случаев плагин все равно работает без проблем, но ведь разработчики не просто так подробили их, а заложили в это (как я думаю) какую то логику. Очень хочется понять эту логику. Причем некоторые action-ы не всегда запускаються, т.е. имеют условие на запуск, тоже интересно знать какие и при каких условиях. И последнее, как я понял я могу создавать свои action-ы и использовать их по аналогии событий в системном программировании, если я не прав поправьте меня.

спс все отлично работает.

vitaly, а есть описание всех полей для файла version у плагина?
Поля нашел, просматривать что каждое из них делает долговато, хотя назначение большинства итак понятно...

Вот то что понял. Поправь и дополни меня пожалуста

id - уникальное имя
name - название (отображаеться в админке)
version - версия
acts - действие при котором запускается плагин (может иметь несколько значений), формат index; nameplugin.php
здесь сразу вопрос: какие acts бывают и какой их порядок вызова (или прикаких условиях)
file - ????????????????????????
config - файл конфигурации
install - файл установки плагина
deinstall - файл удаления плагина
management - ???????????????????????????
type - тип (видел только plugin)
Вопрос: какие типы еще бывают
description - описание (отображаеться в админке)
author - автор (тоже видно в админке)
author_uri - страничка автора (тоже в админке)
permanent - ????????????????????????????????????
library - ???????????????????????????????
actions - тоже что и acts

Как я понял, надо поиграться с переменными $SUPRESS_TEMPLATE_SHOW и $SUPRESS_MAINBLOCK_SHOW.

спс vitaly, теперь немного разобрался, думаю за пару недель переберусь на платформу ng.
Жаль нет встроенной возможности создавать разные группы пользователей и управлять правами доступа, прийдется быстренько наваять временное решение.