Комментарии / Публикации aVadim / Alto CMS

+62.91

154.072

Вадим

Но тогда зачем такой шаблон в наличии?

До сих пор есть сайты, которые в силу разных причин работают на версии 0.9.х

Есть ли способ мне попасть в админку?

Если юзер был авторизован с «запоминанием» авторизации, то можно напрямую site.com/admin

Тогда попробуйте так: обновите у себя в модуле ModuleSession только метод SetCookie(), взяв его из последней версии движка 1.1.13, и включите константу DEBUG, как сказано выше в п.2

И смотрите логи. Если кука не ставится из-за того, что до этого момента был какой-то вывод, то в логах будет указано, в каком файле и в какой его строке был этот вывод.

На днях была похожая проблема — долго не могли понять, почему на одном сайте при подключении плагина не ставится кука. Долго ковырялись, не могли понять, и выяснилось, что один из подгружаемых файлов в кодировке UTF-8 BOM, и из-за этого идет вывод. А при любом выводе куки не устанавливаются.

Могу посоветовать следующее:
1) Обновиться до 1.1.3
2) В начале файла /index.php добавить:

define('DEBUG', 1);

3) А в /app/config.local.php добавить:

$config['sys']['include']['check_file'] = false;

Если какие-то файлы имеют подключаемую кодировку UTF-8 BOM, то увидите сообщения в логе error.log

Посмотрел по коду — готового механизма сброса счетчика нет, к сожалению.

… как получить url этого счётчика

А вот это не понял вопрос. Есть метод, с помощью которого значение можно получить:

E::ModuleUserfeed()->GetCountTrackNew($iUserId)

Если нужно, то можно в плагине определить экшен, который по URL будет вызывать этот метод и выдавать значение. Но готового URL нет

Как-то не очень понятно: при авторизации кука проставляется, а после редиректа пропадает? И это все на одном домене, без переходов?

Методы Config::ReadPluginConfig()/Config::WritePluginConfig() работают с базой данных, поэтому смысла нет вызывать их при до загрузки ядра. Не знаю, возможно, стоит выбрасывать исключение, когда они вызываются в неположенном месте, чтоб разработчику было понятно.

Но если в вашем случае вызвать Config::Get('router.uri') в любом экшене, то должно вернуть верные значения. Или, например, можно повесить хук на 'action_before' (он вызывается ДО того, как будет определен класс экшена для обработки URL).

fix — github.com/altocms/altocms/commit/7e5395c6db2ff4fa2688264d185267b7cae2bc17

Забыл отметить нюанс: при использовании '$roor$' эффект будет при следующей загрузке страницы

На гитхабе обновлена работа с конфигом. Погонял, потестил у себя — работает все так, как ожидается. Допустим, есть плагин 'test' и у него такой конфиг-файл:

$config['zero'] = 0;

И мы можем получить значение конфига плагина обычным путем:

// Получить значение конфига плагина
Config::Get('plugin.test'); // ['zero => 0]

Но можем так же прочитать те значения конфига плагина, которые сохранялись через Config::WritePluginConfig():

// Получить значение сохраненного конфига плагина
Config::ReadPluginConfig('test'); // null

Изначально это — null.

Теперь сохраняем программно новые значения и смотрим, что имеем на выходе:
Config::WritePluginConfig('test', ['one' => 1, 'two' => 2]);
Config::Get('plugin.test'); // ['zero => 0, 'one' => 1, 'two' => 2]
Config::ReadPluginConfig('test'); // ['one' => 1, 'two' => 2]

Т.е. обычный Config::Get() возвращает все ключи конфига, как из конфиг-файла, так и сохраненные программно, а Config::ReadPluginConfig() возвращает только программно сохраненные ключи конфига.

Еще примеры программных манипуляций конфигом:

// Сброс конкретного ключа
Config::ResetPluginConfig($sPluginName, 'one');
Config::Get('plugin.test'); // ['zero => 0, 'two' => 2]
Config::ReadPluginConfig('test'); // ['two' => 2]

// Сброс всех сохраненных настроек конфига заданного плагина
// Настройки, заданные в конфиг-файле плагина не меняются
Config::ResetPluginConfig($sPluginName);
Config::Get('plugin.test'); // ['zero => 0]
Config::ReadPluginConfig('test'); // null

// Сохранение ключа 'webpaths'
Config::WritePluginConfig($sPluginName, ['webpaths' => ['foo']]);
Config::Get('plugin.test'); // ['zero => 0, 'webpaths' => ['foo']]
Config::ReadPluginConfig('test'); // ['webpaths' => ['foo']]

// Значение ключа 'webpaths' будет заменено на новый массив
Config::WritePluginConfig($sPluginName, ['webpaths' => ['bar']]);
Config::Get('plugin.test'); // ['zero => 0, 'webpaths' => ['bar']]
Config::ReadPluginConfig('test'); // ['webpaths' => ['bar']]

// Действие, аналогичное директиве config['$root$'] в конфиг-файле плагина
Config::WritePluginConfig('test3', ['$root$' => ['router.uri' => ['aaa' => 'bbb']]]);
Config::Get('plugin.test'); // ['zero => 0, 'webpaths' => ['bar']]
Config::ReadPluginConfig('test'); // ['webpaths' => ['bar'], '$root$' => ['router.uri' => ['aaa' => 'bbb']]]

Последний пример примечателен тем, что через конфиг плагина он воздействует на общий конфиг приложения — добавляет значение в секцию 'router.uri'.

В принципе, мы могли бы воздействовать на конфиг приложения напрямую через Config::Set() или через Config::WriteCustomConfig(). Но использование Config::WritePluginConfig() является более предпочтительным и вот почему: если плагин отключается в админке, то все его настройки, которые были сделаны через Config::WritePluginConfig() также будут отключены автоматически.

А что значит «динамическое переопределение»? Это нужно заново переопределять при каждом запуске?

Вызывать эти методы до того, как загрузится ядро движка (класс Engine), нельзя, т.к. там идет обращение к базе данных, а это идет уже через модуль БД, а он вызывается через ядро.

Получается, тут надо две задачи решить:
1) Определение языка статьи
2) Фильтр списка статей по языку

Без дополнительных плагинов это не решить. И п.1 я бы решал «в лоб» — добавил бы дополнительное поле в таблицу prefix_topic, куда сохранял бы язык, который явно указывается при создании статьи.

А п.2. решается изменением фильтра топиков. Если будете писать плагин и будут вопросы — могу расписать более подробно.

Обновите плагин гостевых комментариев (сегодня опубликована версия 1.1.4, где был исправлен ряд ошибок). Возможно, проблема будет решена

Я не понял проблемы, уточните, пожалуйста, в каком случае игнорируются русские статьи?

Если есть вопросы, пишите сюда: altocms.ru/blog/questions/

Все (подчеркиваю — ВСЕ!) изменения основного конфига нужно выполнять ТОЛЬКО в app/config/config.local.php.

Почти наверняка у вас на сайте включена директива magic_quotes_gpc. Для php 5.3 и выше она должна быть отключена по умолчанию, но до сих пор встречаются хостеры, где она включена.

Отключите ее или обратитесь к хостеру, чтоб отключил

Насчет XCache ничего толком сказать не могу. В ЛС класс работы с ним включили из фреймворка Zend, и в оно в Альто перешло как есть. Но сам я не использовал (а мемкеш юзал)

Ну, в общем-то все верно тебе ответили: кеширование байт-кода и кеширование данных по запросу — это разные задачи. Первая решается на уровне серверного софта, вторая — на уровне движка. И в Альто это есть.

определена ли работа с memcache в коде Alto?

Разумеется, задаешь в конфиге:

$config['sys']['cache']['use'] = 'memory';

… и включается кеширование данных с помощью Memcache. Возможно, нужно будет еще задать имя хоста и порта для работы с мемкеш:

$config['memcache']['servers'][0]['host'] = '127.0.0.1';
$config['memcache']['servers'][0]['port'] = '11211';

И если несколько сайтов используют мемкеш-хранилище, то нужно еще для каждого из них свой префикс кеша задать:

$config['sys']['cache']['prefix'] = 'alto_cache';

Посмотрел мельком — модальные окна «войти» и «регистрация» открываются (дальше не проверял).

Но все же — удалите содержимое папки /_run/assets

А шаблон стандартный или что-то переделывали?

aVadim

О себе