Мне лично очень нравится идея edit-in-place, Владимиру — тоже (обсуждали с ним это еще до выхода самого первого релиза Альто). Но личные предпочтения — это одно, а функционал must have — это другое. У меня нет пока окончательного мнения, нужно ли делать это прямо в коробке или лучше в виде расширения реализовать. Есть опасения, что рядовые юзеры (не сайтостроители, а посетители сайтов, созданных на Альто) воспримут это однозначно положительно.

Как пример — форумы vs блоги. До сих пор возникает у многих потребность прикрутить к блоговому движку какой-нибудь форум, т.к. далеко не всегда посетители сайтов поддерживают уход от форумных обсуждений в комменты к топикам.

Кажется, Воланд говорил, что «москвичей испортил квартирный вопрос». А я добавлю — а создателей сайтов испортил ЛС :)

Даже если в админку не войти, то все равно должен быть лог ошибок здесь: /_tmp/logs/error.log
И там наверняка есть информация об ошибках

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

Видел такое, и тоже впечатлился. Но нельзя вот так взять, и поменять всю систему редактирования. Поэтому в 1.0 точно не будет. Но работать в этом направлении нужно, ИМХО

… что это может быть?

Да что угодно это может быть, информации для диагностики нет никакой. Какая версия движка? Какой скин?

Навскидку — какие-то ошибки в джаваскрипте

В версии 0.9.х должны быть права на запись в папки /_run, /_tmp, /upload, а также на файл /plugins/plugins.dat. Обычно достаточно прав 755, но иногда требуется 777

Это пишется про файл smarty_internal_templateparser.php, но он должен быть в той же папке, что и smarty_internal_smartytemplatecompiler.php. Я бы на Вашем месте снес всю папку со Смарти и залил ее заново, возможно, какие-то файлы пропущены

В 0.9.х да, должны подхватиться. В 1.0 механизм ассетов был полностью переписан, и LESS пока не обрабатывается автоматом.

Для начала надо убедиться, что переносится все без кеша (иногда просто копируют папки, включая кеш, чего нельзя делать).

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

Да модуль LESS был добавлен в движок, но в силу некоторых причин пока активно не использовался. Есть в планах прицепить его к обработке asset-файлов. Но пока он лежит просто в виде модуля, назначение и синтаксис методов можно легко понять по исходнику модуля ModuleLess

можно такую вещь провернуть?

Уже провернули

… то Альто думает что это топикИд и вываливает 404

А в каком месте?

Да, исправлено

Ну значит, не посчитали, что этот баг более важен, чем другие. За месяц на гитхабе 76 коммитов, т.е. в среднем больше двух коммитов в сутки. Может, и не очень высокие темпы, но как умеем. В ближайшие дни будет релиз альфа2 и начнется серия публикаций, где более подробно расскажем о нововведениях в версии 1.0

Это все равно что сказать «Иногда что-то не работает». Мы разработчики, не экстрасенсы

Полноценная поддержка PostgreSQL планировалась в версии 1.1, но, похоже, придется пересматривать планы и сдвинуть эту часть работ к версии 1.2. В какие сроки это выльется, сказать не могу, т.к. не приступали даже еще к анализу — что именно сейчас мешает юзать Постгресс. Было б замечательно, если б нашлись энтузиасты, активной работающие с этой базой, которые взяли бы на себя хотя бы анализ текущих проблем в части поддержки PostgreSQL

Здесь у меня вопрос к разработчикам – Можно ли, понимая маппер как интерфейс доступа к данным перенести в него логику работы с КЭШем. При этом если в КЭШе будет результат – возвращать его, а если нет – получать от БД???

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

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

В общем, мой ответ на вопрос: переносить работу с кешем в маппер не стоит.

Пара вопросов по плагину:

1) Версия PHP 5.4 нужна только для примесей? Или где-то еще используются специфические конструкции/ф-ции 5.4?

2) Не вполне понял относительно валидаторов — сейчас в движке уже есть механизм валидации значений, причем, исходящий корнями тоже из Yii. Предлагается иная реализация? Хотелось бы плюсы/минусы понять

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

В текущей дев-версии на гитхабе баг устранен