start-kit удобнее, в плане разработки...

Уф, как бальзам на душу :)

Я для себя выделил только 8 макетов страниц, а остальное это UIkit...

Так, может, поделитесь своим видением? Или это проф. секреты? ;)

Качество адаптивного сайта зависит от дизайнера и верстальщика...

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

Я все жду таких макетов, где бы был не css, а less/sass/stylus, чтобы хотя бы цвета менять на сайте...

Самые первые цветочки уже есть: темизация Start-kit выполняется именно через LESS. А вообще, лучше не ждать, конечно, а самому предлагать конкретные решения. Без опытных верстальщиков, которые не просто руку набили, но и владеют определенными методиками, могут анализировать и систематизировать, очень трудно решить все описанные выше проблемы. Если вообще возможно :)

Само по себе ничего не слетает. Причина должна быть по любому — какой-то плагин поставили, или настройки изменили, или еще что-то. Несколько раз было у моих клиентов, что хостер молча выполнял обновление софта, после которого начинались проблемы у сайтов. А у владельцев сайтов, конечно, возникало ощущение, что «всё слетело само».

Но самая распространенная проблема — это проблема «с www и без»

Может проблема в том, что когда-то www.site.соm, а когда-то просто site.com?

Ну да, прикинул сейчас в уме число экранов для WP — главная, страница, топик с комментариями. Все! Если юзать Альто примерно на уровне WP, то и здесь примерно столько же страниц нужно будет нарисовать (может, плюс парочку). Если юзать функционал по полной, да еще и наращивать его сторонними плагинами, то деваться некуда — надо продумывать. Или, как минимум, надо проверять все экраны, и вот тут этот список очень даже поможет.

По решению — идеального полного решения, наверное, и нет, ибо нет идеала в реальном мире. Но ход ваших мыслей почти один в один совпадает с моими. Вообще, если по хорошему, то, проанализировав этот список, следующим шагом нужно подготовить набор типовых блоков/элементов (методология БЭМ совсем недурная штука), а потом — набор CSS-классов. Это — с методологически. А технологически, тем временем, обеспечить полноценную поддержку LESS и наследование шаблонов, да.

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

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

Плюс возникает вопрос: а как быть с другими ссылками, которые формирует движок? Надо ли ссылки вида site.com/blog/, site.com/profile и т.д. переводить в вид сайт.рф/блог/, сайт.рф/профиль/ и пр.?

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

Таскать за собой все возможные модальные окна плохо...

Согласен. Более того, есть соображения, как этого избежать: при вызове модального окна проверять, есть ли оно на странице, и если нет, то подгружать аяксом. Собственно, это одна из причин, зачем нужно было имя файла шаблона ставить в соответствие с ID окна — имя файла шаблона для подгрузки определяется автоматом.

Будет такое в будущих релизах.

Пример из бутстраповских доков:

<!-- Button trigger modal -->
<button class="btn btn-primary btn-lg" data-toggle="modal" data-target="#myModal">
Launch demo modal
</button>

И вот точно такой же код применительно к сайту на Альто:

<!-- Подключаем шаблон окна -->
{include_once file="tpls/modals/modal.write.tpl"}
<!-- Добавляем кнопку для вызова этого окна -->
<button class="btn btn-primary btn-lg" data-toggle="modal" data-target="#modal-write">
Написать
</button>

И никакого js!

Бутстраповские смотрятся «аппетитнее»

Вы, видимо, не поняли — речь как раз и идет о том, что сейчас ВСЕ окна — бутстраповские! Они бутстраповские и по структуре HTML-кода, и по используемым CSS-классам, и по javascript-модулям. Т.е. Вы можете открыть инструкции Бутстрапа getbootstrap.com/javascript/#modals и действовать строго по ним — как оформляется окно, как управляется, вешать на него события и т.д.

В Альто лишь упорядочены некоторые вещи:

1) Шаблоны окон рекомендуется выносить в отдельные файлы и именовать их определенным образом, чтоб проще было впоследствии их находить, адаптировать, менять, наследовать, короче — чтоб удобней было с ними работать.

2) Создана javascript-обертка для унификации программного интерфейса работы со всеми окнами — и шаблонными, и системными (см. часть 2)

Какие-то решения, скажем так, исторически сложились. Например, тот же вызов методов через подчеркивание. Да, в перспективе хотелось бы уйти от этого, и даже есть некоторые наработки:
altocms.ru/blog/339.html
altocms.ru/blog/extensions/374.html

Но на текущем этапе, считаю, есть более насущные задачи.

Структура папок…

Структура папок движка в целом: altocms.ru/blog/dev/418.html
Структура папок нового шаблона: altocms.ru/blog/skins/551.html

Повсеместно используется DbSimple, хотя на всех хостингах уже давно поддерживается PDO

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

По умолчанию подключение идет через mysqli, но можно и через PDO подключаться. Сейчас есть люди, которые работают с PostgresSQL, и уже немало замечаний было выдано относительно работы с этой базой. Если возьметесь оттестировать работу через PDO, будет здорово.

без мелкого патча на windows она тормозит движок почти на секунду

А что за патч? Только под Виндой он нужен?

Я как-нибудь постараюсь изложить свои мысли обо всем этом в отдельном топике, раз уж вы не против

Не то что бы не против — я категорически ЗА!

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

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

Тогда проще всего, наверное, доработать крон до асинхронного запуска...

Идея «центрального крона» (т.е. некоего единого компонента, который должен дергаться каким-то образом и разруливать все отложенные события) высказывалась давно, еще в обсуждениях ЛС до рождения Альто. Но пока просто руки не дошли до него. И этот функционал, конечно же, должен быть в ядре, тут плагином не обойтись.

… а другие прибиты даже не гвоздями, а шурупами: те же типы полей...

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

А какие еще вещи «шурупами прикручены»? Свежий незамыленный взгляд и конструктивная критика — это всегда полезно

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

а) для разнообразия (захотел — поменял)
б) для того, чтоб можно было отключить виджет topbanner_image и включить виджет topbanner_slider здесь: common/templates/skin/start-kit/settings/config/widgets.php Тогда вместо статичного баннера будет автослайдер.

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

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

Привязка плагинов к домену — это инициатива авторов платных плагинов, защита от несанкционированного распространения. И тут уж авторам никто диктовать не может, каждый сам определяет политику распространения

Но что у вас, что у ls от версии к версии ломается чуть ли не все

У ЛС это традиция, да :) Там даже каждая новая минорная версия несовместима с предыдущей. У Альто, конечно, релизов пока не так много, но с самого начала вопросам совместимости уделяется огромнейшее внимание (иногда мне это даже в упрек ставят, что слишком большое). У нашего движка есть принципиально иные механизмы расширения, нежели у стареньких WP и проч., поэтому есть возможность, развивая ядро движка, обеспечивать обратную совместимость.

Что из себя будет представлять 2.0, как там будет решаться проблема совместимости с веткой 1.х — об этом пока рано говорить. В нашей сфере так быстро все меняется…

Что касается других вопросов (oEmbed, og) — подумаю

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

Но если не цепляться за термины, то ход мыслей верный, примерно в этом направлении и планируется развивать