столкнулся с проблемой, что нужного размера автарок не существует

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

Проверьте для начала логи — нет ли там ошибок. А затем надо смотреть, какие пути прописываются у аватар

Если задать в админке принудительную обработку css/js (там же, где отключается их слияние), то кеш сбрасывать не обязательно, файлы будут принудительно перезаписываться

Встроенной опции такой «из коробки» нет, хотя вы уже не первый, кто про это спрашивает, видимо, стоит в будущих версиях предусмотреть.

Причём в панели хостинга видно, что письма отправляются

Тогда это вопрос, скорее, к саппорту хостинга. Возможно, почтовики по каким-то причинам считают письма спамом

А по п.2 мало информации: надо знать, что и как пытаетесь изменить, чтобы дать какие-то советы

Поймите правильно — я совсем не против обсуждения проблем, Более того: они нужны и полезны. Только лучше а) делать это в специально для этого предназначенном месте; б) описывать проблему максимально подробно: делаю раз, делаю два, делаю три — получаю то-то и то-то. И не забывайте заглядывать в лог ошибок _tmp/logs/error.log.

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

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

А где, в каком конкретно месте сайта это происходит? И в какой ситуации? При вводе логина/пароля во время авторизации? Или вообще везде, где есть на сайте логин? Если смотреть, например, список юзеров, или авторов топиков/комментов — преобразования тоже есть?

Вот взять юзера dimitr — у него везде в кириллицу преобразуется? Или где-то так, а где-то эдак?

fixed

Все круче — это баг PHP: bugs.php.net/bug.php?id=64695

Вадим, можно вопрос — а какая версия DAO у Вас используется сейчас на сайте?
И соответственно на каком из коробочных шаблонов основан данный сайт?

DAO версия 3.2.2, а вот шаблон не коробочный, делался индивидуально, но структурно он близок к шаблонам LS 1.0.3

Если по всем правилам, то нужно бы так. Но есть одна проблемка: для полноценного бета-тестирования необходимо, чтоб новая версия сайта работала в «боевом» режиме. Т.е. юзеры, которые туда приходят, не просто попробовали создать топик, коммент и т.д., а чтоб они работали с сайтом, как обычно, и чтоб весь контент, создаваемый ими, сохранялся. Но при этом часть юзеров будут работать со старой версией сайта, создавая контент. А базы-то разные!

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

Поэтому все делалось по упрощенной схеме:
1. Новый тестовый сайт был поднят параллельно с тестовой базой и какое-то время тестировался и правились баги.
2. Был создан удаленный git-репозитарий для нового сайта, куда была залита новая версия
3. На рабочем сервере был создан клон репо с новой версией
4. На рабочем сайте прямо через index.php была включена заглушка о том, что идут технические работы
5. Создана копия рабочей базы и на новую базу накатились правки
6. С помощью rsync из локального репо в рабочую папку сайта была залита новая версия
7. Правка параметров подключения в /app/config/config.local.php и списка активированных плагинов
8. Убирается заглушка и сайт работает

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

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

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

Нет, не означает. Я не знаю планов разработчика DAO, поэтому не могу делать таких заявлений. Но адаптация любого плагина может вестись с двух сторон — со стороны плагина, и со стороны движка. И я готов приложить усилия для обеспечения обратной совместимости со стороны движка — я это имел ввиду.

Если проблему с заменой названия страны на ее ID решили, то дальше все просто — в конфиг-файле app/config/config.local.php надо задать переопределение:

$config['router']['uri'] = array(
    '[~^people/strana/(\w+)]' => 'people/country/$1',
);

В конфиг-файл app/config/config.local.php добавить:

$config['router']['uri'] = array(
    'talk/*' => 'error/404',
);

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

Сегодня посмотрим, исправим

Все три плагины активировались. В логах никаких ошибок нет?

Если загружаете не через админку, а руками заливаете на хост, то проверьте права на папку и файлы

Ну вот, это уже конкретика. Проверю

Даже не распаковывал, а просто загрузил zip-архив через админку и активировал:

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

Для проверки я только что установил с нуля движок, и взял из каталога последний из плагинов altocms.ru/addons/download/item/124/ — плагин активировался без проблем