Такого рода ошибки чаще всего исправляются сбросом кеша

Раньше «Прямой эфир» заполнялся, когда сама страница формируется, а сейчас так: сначала выводится страница, а потом уже аяксом подгружается прямой эфир. Т.е. юзер страницу видит чуть-чуть быстрее. У Вас, видимо, по какой-то причине подгрузка автоматом не выполняется

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

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

Кстати, хорошая штука — концепция виджетов в Alto, я в LS не слышал про них, это некоторое нововведение получается?

В этом месте хочется запрыгать и закричать: «Да-да, там ничего такого нет! Это все я придумал!..» :)

Хотя это, конечно же, не так. В LS есть «блоки» — хорошая идея, но не очень удачная, на мой взгляд, реализация (мне и сам термин «блок» кажется неудачным, и «правила», с помощью которых он задается). Виджеты — это развитие концепции LS-блоков.

Да, посмотрел код — есть баг в 0.9.7.1, из-за которого не выполняется проверка.

Исправляется так: в модуле User.class.php в функции public function CheckLogin($sLogin) находится код:

if (!$sCharset || $nMin || $nMax) {
    return true;
}

и меняется на такой:

if (!$sCharset || !$nMin || !$nMax) {
    return true;
}

Присоединяюсь к поздравлениям!

Не вполне понимаю, что значит «почти чужой». Да, создается не с полного нуля: css-классы — от Bootstrap, js-плагины — от jQuery, верстка — от vOFFka, js-модули движка — на базе наработок deniart'а. Но с использованием этих ингредиентов сейчас вручную собирается шаблон специально для Альто

А какая версия движка? Может, баг какой-то, из-за которого проверка не срабатывает, но который был позже исправлен

Эта запись означает, что в логине допустимы:
* цифры от 0 до 9
* буквы от a до z
* символ подчеркивания
* дефис

Ох, Андрей, ну как всегда — если копнешь, так до самых глубин :) (это я в одобрительном смысле, если что)

Про JSLint помню. По большому счету, соглашения JSLint должны быть составной частью Alto Coding Style. А так же составной частью должны стать правила (кроме php и js) еще и для css и tpl.

Объект ls сейчас — неймспейс для большого набора функций. Нужно ли это оформлять, как jQuery-плагины? Честно говоря, не даже думал об этом, поэтому пока не могу ни согласиться, ни возразить. Если есть какие-то аргументы «за», то рад буду услышать.

Модульность js-скриптов — да, отдельная тема. Собственно, еще в ЛС был заложен механизм, позволяющий группировать js- и css-файлы в разных комбинациях и загружать на разных страницах разные наборы. Но как-то особо не прижилось пока. Рассуждая чисто теоретически, трудно сказать, какой подход лучше — сформировать один набор, который будет грузиться на всех страницах, либо делать разные наборы. В первом случае можем получить выигрыш за счет кеширования, во втором — за счет уменьшения размера наборов. Где выигрыш будет больше — это только эксперименты могут показать.

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

Что-то не пойму этой проблемы с аватарами. А путь какой к ним формируется?

Был такой баг, но весь вышел

После RC не будет никаких изменений в структуре базы данных, не будет никакого принципиально нового функционала, только фиксы. Поэтому даже не знаю, какие могут быть потери.

Другое дело, что у кого-то УЖЕ есть работающие проекты на предыдущих версиях, вот им лучше, наверное, дождаться финала

Спасибо, поправил. И это, конечно, общая схема, в конкретной реализации могут быть некоторые изменения. Например, склоняюсь к тому, что лучше не trigger() использовать, а triggerHandler(). Плюс, можно попробовать не напрямую использовать триггер, а через некоторую обертку, чтобы контекст сразу в this передавать в функции обработчике. Или это лишнее уже?

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

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

Принципиальное решение принято, но детали еще обдумываются. Описал здесь, как примерно это планируется делать: altocms.ru/blog/dev/530.html

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

Свое/не свое — это все гордыня, или, говоря по-пацански, — понты. Более важно, насколько это способствует развитию движка. Тем более, что developer-kit ведь не целиком берется, как он есть, оттуда используется разметка и классы стилей, которые, в свою очередь, базируются на бутстраповских классах. А вот структура шаблона, принципы работы с ним и т.д. — это свое. Но не потому свое, что просто так захотелось, а потому, что это долго обдумывалось и продумывалось, и, в итоге, было решено, что так — лучше.

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

Не знаю на сколько это справедливо для StartKit...

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

Активируем плагин совместимости...

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

1) Запись с ключом custom.config.view.skin удалить
2) Очистить папки /_tmp/cache/ и /_run/
3) В файле /app/config/config.local.php задать нужный скин:

$config['view']['skin'] = 'synio';