Все просто, но в тоже время и нет…
Первое правило — не трогать все, что находится в папках /engine, /common/classes и /common/classes/config
Второе правило — для любого изменения функционала — пиши плагин, ибо в плагине можно переопредилить классы движка, написать свои экшены, переопределить шаблоны и сделать почти все что угодно, кроме изменения двух системных классов (но оно вам и не понадобится)
Для более полной информации посмотрите вот это видео:
youtu.be/Kq35JnRI9hk?t=14m35s
Это доклад Вадима Шемарова (aVadim ) на конференции CMS Conference 2013 — очень полезное видео.

Да, можно. Приоритет будет выше у конфига скина. Все то, что есть по умолчанию в конфиге движка можно (и нужно) переопределять в конфигах плагинов, скинов и в папке app/config
Так вы сможете обновлять движок и при этом не терять свои наработки и настройки конфигов.

Капча это здорово, давно хотел сам от Yii прикрутить. Спасибо, утащил к себе в копилку.

Странно все это… сейчас проверил на свежей версии 1.0 (с GitHub) — у меня такого глюка не наблюдается.
Скачайте свежую версию с гита github.com/altocms/altocms и обновите файлы на сервере. (только папки common и engine)
Попробуйте

$config['smarty']['force_compile'] = true;

Попробуйте проверить вот эти настройки.

$config['smarty']['compile_check']          = true;   // Проверять или нет файлы шаблона на изменения перед компиляцией, false может значительно увеличить быстродействие, но потребует ручного удаления кеша при изменения шаблона
$config['smarty']['force_compile']          = false;  // Принудительно компилировать шаблоны 
$config['smarty']['cache_lifetime']         = false;  // Кеширование отрендеренных шаблонов

Если вы меняете только CSS, то обновляйте страницу браузера через Ctrl+F5 (полное обновление странцы)
Проверьте настройки сервера, сервер может кешировать статические файлы. Если у вас shared хостинг, то спросите у тех.поддержки хостинга, так как кеширование на стороне сервера часто применяется для снижения нагрузок, особенно если стоит связка nginx+apache или хостинг облачный.

Спасибо! Давно хотел детально разобраться, а вы сэкономили мне время, да еще и макрос сделали — супер!

Кому нужно, вот коммит на github, который этот баг исправляет:
github.com/altocms/altocms/commit/a5d9973f87c3bca75cf02794a14ec9cf1398497d

Точно не скажу… у всех по разному. Ограничения чаще всего стоят на количество писем в час.
Вот данные прошлого года:
mail.ru — не более 1 письма в минуту
yandex.ru — не более 500 писем в сутки, не более 25 адресатов в одном письме
gmail.com — не более 2000 писем в сутки и не более 500 получателей в одном письме за раз при отправке через интерфейс gmail.com (через web-интерфейс, т.е. при входе через браузер), не более 100 получателей в одном письме за раз при отправке через ваш почтовый клиент или через шлюз
rambler.ru — не более 200 писем в час

Но учтите, что на shared-хостингах ограничения бывают еще жёстче.

VPS-кой управлять не сложно, не намного сложнее чем сайтом в целом.
По ценам:
Сайт подбора VPS по ценам и характеристикам — poiskvps.ru/
А вот VPS-ка за 99 р/мес. по отзывам вроде не плохо — infobox.ru/vps/linux/

Яндекс, Google Apss, Bing (он тоже дает почту для доменов) лучше по нескольким причинам:

— на shared-хостингах (почти на всех, за очень редким исключением) услуги почтового сервера предоставляются по остаточному принципу, а это значит что и за их безопасностью следят тоже по принципу — работает и ладно.

— Яндекс etc почту защищают хорошо, + защита от спама и фишинга намного более продвинутая, +они все имеют DKIM и через их сервера почта дойдет (при отправке с сервера) гарантированно, что нельзя сказать о почтовом сервере хостинга, так как его IP может уже давно в бане у всех ведущих провайдеров почты по причине спама с их IP на котором может висеть пара сотен сайтов.

— Google Apss имеет двухфакторную авторизацию у Яндекса это тоже в ближайших планах.

Это только основные преимущества, о менее значимых можно написать еще больше.

1. Меняйте хостинг (лучше взять недорогой VPS около 100р/месяц)
2. Не используйте почту на хостинге (есть яндекс почта для домена, есть google apps и т.д.)
3. Не используйте FTP (пользуйтесь SFTP с авторизацией по ключам)
4. И да, используйте сложные пароли и для любого сайта, почты и так далее пароль длжен быть разный. Для простого и удобного хранения паролей используйте KeePass

Почитайте вот эту статью, написанную мной для LS, но и в Alto она не теряет актуальности.
livestreet.ru/blog/13290.html

Бесплатный OpenID — работает, но с небольшими переделками. Платный — не пробовал, но уверен, что и он не потребует каких-либо сложных действий… или вообще из коробки заработает.

А я уже собрался искать причину этого глюка… вот что значит, прежде чем ломать, почитай инструкцию! Спасибо!

На всякий случай всем — все настройки делайте через админку, напрямую редактировать config.php не стоит, кроме одного:

config['sys']['mail']['smtp']['secure']   = 'здесь указываем нужные значения'

значения могут быть:
ssl
tls
false
зависит от наличия (или отсутствия) и типа шифрования у почтового провайдера

Да, есть такой глюк. Завтра собираюсь выяснить почему, как выясню — напишу вам.

так это все нужно настраивать в записях DNS, генерить ключи для DKIM — проще все это поручить pdd.yandex.ru если писем уходит не много.
для серьезной нагрузки, да — поднимать свой почтовый сервер.

встроенный клиент работать будет, но письма от него не все почтовики будут принимать.

В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

help.yandex.ru/mail/mail-clients.xml#pop3

вы в своем аккаунте на яндексе разрешили доступ из почтовых клиентов?
пробовали 25 или 587 порты без шифрования?

Происходит перемотка не на конец статьи, а к форме комментариев (форма стразу открыта) — значит происходит какое-то событие, которое открывает форму комментов и страница перемещается к ней.
Дабы не искать иголку в стогу сена, ответьте на следующие вопросы:
-Когда это началось или так было всегда?
-Если не всегда, то что перед этим ставили или меняли?
-Такое поведение страниц происходит при авторизации через социалки, а при нормальной авторизации (логин-пароль) точно так же?
Ну и попробуйте отключить все сторонние плагины и посмотрите поменялось ли что-то, если проблема пропала — ищите виновника.