Значит, тут, скорее всего, имеет место проблема сохранения сериализованных данных в базе. Вылечить можно только вручную, поняв, с каким топиком проблема.

Но понятно, что нужно предпринимать меры на уровне движка, чтоб таких проблем не возникало.

Бытует мнение, что сообщения класса E_NOTICE — это как бы вовсе и не ошибка, а просто уведомление, поэтому можно на них не обращать внимания, а лучше просто отключить. Я лично так не считаю, это, конечно, как правило, не критично, но в системе, где все отлажено, таких сообщений быть не должно.

Возможно, поможет сброс кеша

А какая именно проблема? Аватары, которые были загружены с кривыми настройками php, скорее всего, в базе так и были сохранены. Их надо загружать заново или править в базе пути

Вот-вот, у меня та же байда была. Долго не мог понять, почему с одинаковыми параметрами на локалке все ОК, а на внешнем хосте — проблемы. Начал уже тупо код разбирать чуть ли не по каждой строчке, анализируя, что происходит, пока не увидел, что уже из $_POST получаю заковыченные значения. Я никак не мог предположить, что эта директива может быть включена в версии 5.3, т.к. в этой версии она считается устаревшей и из движка был удален код, ее проверяющий

Вы откопали интересную фичу, которая, на мой взгляд, еще недостаточно была отработана, потому-то она и не объявлялась публично. И пока есть более приоритетные задачи по багфиксам, поэтому даже не смотрели еще. Но и до нее дойдет очередь

Я много времени и сил вложил...

Не поверите — я тоже. Несмотря на утверждения, что обычно ничего не фиксится, а тикеты просто закрываются. Но как я уже не раз говорил — в 1.0 впредь будут фиксится только критические баги, а именно — либо приводящие к фатальным ошибкам, либо создающие проблемы безопасности.

Недавно внезапно возникла подобная проблема. Оказалось, что хостер чего-то у себя обновлял, и для php 5.3 почему-то вдруг включилась по умолчанию директива magic_quotes_gpc

В общем, проверьте, не включена ли magic_quotes_gpc

Вообще-то правильный ход такой: если надо перенаправить запросы с site.com/community на site.com/blogs, то в конфиге это записывается так

$config['router']['rewrite'] = array(
    'community' => 'blogs',
);

Но честно признаюсь, не проверял, какие при этом формируются мета-теги, проверю

done — github.com/altocms/altocms/commit/72003e991154166a573a2a61874043c020f6eded

Хороший вопрос! Кажется, до сих пор никто не озадачивался им, и поэтому какой-то специальной страницы для вывода всех тегов просто нет.

А какой шаблон?

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

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

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

Часть тикетов от inliquid — это вообще про версию 1.0.

Сейчас будет череда фикс-версий с исправлениями и некоторыми улучшениями, это процесс непрерывный.

В любом случае, я понял, что ответ «нет».

Пока нет. В задумках такая фича есть

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

Ну так просто же — все что нужно, это один раз дернуть любую страницу сайта с параметром ?lang=xx.

Например, добавляете в форму настроек юзера поле с языком. И, в зависимости от выбора юзера меняете джаваскриптом адрес отправки формы, т.е. задаете в атрибуте action значение ?lang=ru или ?lang=en. И все! Со стороны сервера даже трогать ничего не придется, движок сам запишет языковую куку.

Годится такой вариант?

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

По идее достаточно прописать нужную куку в браузер и все

Тогда я что-то не понимаю. При настройках по умолчанию при вызове типа site.com/?lang=ru нужная кука автоматически пишется самим движком без дополнительных телодвижений. В чем тогда проблема? На вашем сайте язык переключается при вызове с параметром lang=ru? Потом при переходе по разным ссылкам язык сохраняется?

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

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

Но если все ж задаете какие-то кастомные настройки, и пишете свой плагин, в котором сохраняете эти самые настройки, то тогда в нем можете реализовать расширенный метод инициализации сущности, примерно так:

class PluginCustom_ModuleUser extends Module {

    public function Init() {
        parent::Init();
        if ($this->oUserCurrent) {
            Config::Set('lang.current', 'en');
        }
    }
}

Все уже придумано и все гораздо проще :) Если в конфиге не меняли языковые настройки по умолчанию, то достаточно перезагрузить страницу сайта (любую) с параметром lang=en. Например, так: site.com/settings/?lang=ru

Но, повторюсь, это можно сделать на любой странице. Например, можно добавить в шаблон такой код, который будет выводиться на всех страницах сайта:

<a href="?lang=en">EN</a>
<a href="?lang=ru">RU</a>

Тогда при клике на первую ссылку сайт будет отображаться на английском, при клике на вторую — на русском (независимо от того, авторизован ли юзер).

По умолчанию языковые настройки сохраняются только на время текущей сессии. Если хотите, чтобы они сохранялись в куках на бОльший срок, добавьте в app/config/config.local.php строку:

$config['lang']['save'] = '1 year';

Для начала я посоветую эти статьи:
Структура папок и статические файлы
Конфигурация сайта на Alto CMS — некоторые нюансы и особенности

Это не прямые ответы на вопросы, но они помогут лучше понять структуру и принцип конфигурирования движка.

Теперь отвечаю непосредственно на вопросы.

1) app/templates/

По умолчанию оттуда берутся только языковые глобальные файлы и конфиги скинов. Т.е. вы можете положить языковой файл app/templates/language/en.php и его значения буду перекрывать те значения, что лежат в common/templates/language/ru.php. Причем, вовсе не обязательно все значения переписывать в /app/..., достаточно только требуемые.

Текстовки плагинов тут не переопределяют, об этом см. ниже.

Можно также переопределить конфиги конкретного шаблона, например так:
app/templates/skin/experience-simple/settings/config/config.php

В этом примере переопределяется конфиг скина experience-simple.

А вот насчет путей к шаблонам — это ведь настраивается. В конфиге сайта есть такое:

$config['path']['skins']['dir'] = '___path.templates.dir___/skin/'; // путь к папке для скинов

Это как раз то, откуда будут загружаться шаблоны. По умолчанию они загружаются из common/templates/skin. Соответственно, если в app/templates/skin положить свой шаблон, то он будет игнорироваться. Но если есть желание, чтобы они брались оттуда, то это можно указать в конфиге, например, так:

$config['path']['skins']['dir'] = '___path.dir.app___/templates/skin/'; // путь к папке для скинов

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

2) app/config

Именование config.local.php — это исторически так сложилось (в ЛС этот файл лежит в общей конфиг-папке). Файлы `jevix.php`, `menu.php`, `widgets.php` нужно класть в app/config именно с такими именами, без дополнительных суффиксов.

3) app/plugins/

В первую очередь эта папка для хранения plugins.dat. Плюс там же по умолчанию ищутся языковые файлы плагинов. Так можно переопределить текстовки плагина similartopics:
app/plugins/similartopics/templates/language/ru.php

Но сами плагины размещаются в `common/plugins/`, все верно.

В файл app/config/config.local.php добавьте строку

$config['db']['params']['charset'] = 'utf8';