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

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

$config['module']['uploader']['images']['default'] = array(
    // ...
    'original' => array(
        'save' => false,            // надо ли сохрагять оригинальное изображение
        'suffix' => '-original',    // суффикс оригинального изображения
    ),
    // ...
);

PHP-код в шаблонах Smarty не работает.

Если без всяких плагинов и максимально просто, то я бы так советовал:

В /app/config/config.loca.php вставляется примерно такой код

if (isset($_SERVER['HTTP_REFERER']) 
    && preg_match('#^http(s)?://(www\.)?(google|yandex)\.(com|ru)#', $_SERVER['HTTP_REFERER'], $aM)) {
  define('REFERER', isset($aM[3]) ? $aM[3] : '');
}

А в шаблоне в нужном месте так

{if $smarty.const.REFERER=='yandex'}
<!-- код для пришедших с Яндекса -->
{elseif $smarty.const.REFERER=='google'}
<!-- код для пришедших я Гугла -->
{else}
<!-- код для всех остальных -->
{/if}

Бета и публичная демка — на этой неделе

Не разобрались, в чем была проблема?

К сожалению, в этом проблема большого числа хотелок — формулируются по принципу «раз это нужно мне на моем любом сайте, значит это нужно всем и обязано быть в движке»

Потому что был баг, исправлено: github.com/altocms/altocms/commit/b12f37575753530970a87bb9e76355dd30c92990

Вообще-то, там не должно быть ни блога, ни сообщения, это окно создания статьи/топика/контента. Поэтому, на мой взгляд, там должны быть только виды контента и больше ничего.

Я не понял Вашего вопроса

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

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

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

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

Еще раз: я уверен, что на подавляющем числе сайтов разных типов контента единицы, и они вполне укладываются в один ряд. И для них это ухудшение

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

Для чего разные каталоги с конфигами?

Все, что выше я писал для конфигурации плагинов, все это верно и для конфигурации самого движка.

Т.о. каталог common/config — это для конфигов движка по умолчанию, а app/config — для конфигов уже конкретного сайта, которые вы правите, как вам угодно.

В чем разница в каталогах:
app/plugins и common/plugins

В common/plugins кладутся плагины, как есть, а app/plugins рекомендуется использовать для конфигурации плагинов.

Например, вы устанавливаете плагин abc. Это значит, что сам плагин будет установлен в папку common/plugins/abc, а его конфиг-файл будет в папке common/plugins/abc/config. Нередко конфиг-файлы плагинов приходится править, подгоняя параметры под себя. Но тогда при обновлении плагина нужно быть очень аккуратным, чтобы не затереть исправленный файл. А если в новой версии плагина в конфиг внесены новые параметры? Тогда приходится брать дефолтный конфиг от новой версии, свой исправленный конфиг и конструировать сводный файл.

А если у вас с десяток плагинов требуют обновления? В общем, морока еще та.

Всех этих проблем можно избежать в Альто, если скопировать конфиг-файл плагина в папку (именно конфиг-файл, не сам плагин) в папку app/plugins/abc/config и править его под себя уже там. Тогда обновление плагинов можно выполнять, как правило, простым копированием в common/plugins/abc. А движок сначала загрузит конфиг из common/plugins/abc/config, а затем дополнит его данными из app/plugins/abc/config.

Сделал вывод что плагин Nice URL не совместим с ALTO.
Мне-то ладно, я для теста использую 12 статей, а если статей будет больше? Думаю надо пофиксить

Не, это как раз не баг, а фича. Сам по себе плагин Nice URL ужасно костыльный, поэтому даже под LS его использование я бы не рекомендовал. А вот под Альто он и вреден и попросту не нужен, т.к. ЧПУ у Альто работают «из коробки» с самого первого релиза.

Чтобы все работало как надо, без всякого NiceURL в админке идете в «Настройки сайта \ Ссылки». И там задаете формат ссылок, как надо. И важный момент — обратите внимание на блок в конце страницы:

Если у вас число статей без ссылок больше нуля, то стоит выполнить генерацию ссылок

Кому интересна тема, продолжение здесь: altocms.ru/1038.html

Просьба: в топиках, которые занимают по высоте больше полвины экрана, ставить тег <cut>, чтобы в ленте не выводился весь текст, так удобнее для посетителей сайта.

Теперь по теме.

Я — один из создателей проекта Альто, но я постараюсь быть объективным. Скажу сразу, что с Instant CMS мне лично сравнивать сложно, т.к. я не работал плотно с этой системой и не анализировал, как она устроена внутри. Есть чисто субъективные впечатления из разряда «нравится/не нравится», но это все субъективная вкусовщина.

А вот с LS я знаком очень хорошо. Более того, я и есть автор той самой «левой» админки, которая долгое время была самым популярным плагином LS. :) И если сравнивать Alto и LS, то получается такая картина: версия 1.0.3 (нынешняя стабильная версия) очень сильно проигрывает Альто по функционалу. Оно в принципе не может быть иначе, т.к. движок Альто вобрал в себя все, что было в 1.0.3 и плюс туда было добавлено много из того, что на LS делалось плагинами. Но зато в каталоге LS очень много разных плагинов и шаблонов, это верно. И это, разумеется, весомый плюс. Но засада в том, что все эти плагины и шаблоны станут мертвым грузом, как только выйдет версия LS 2.0. Какое число из имеющихся шаблонов и плагинов будет адаптировано под 2.0 — покажет время. Но произойдет это точно не очень быстро, и точно адаптироваться будет намного меньше половины.

Ожидаемая версия LS 2.0 будет очень сильно переработана, и все старые плагины и шаблоны на ней работать не будут. Хотя сама по себе она обещает быть неплохой. Если бы она вышла уже сегодня (или в самое ближайшее время), то, наверное, она в чем-то была бы лучше Альто версии 1.1, а в чем-то Альто был бы лучше. Т.е. с точки зрения пользователя LS 2.0 и Alto 1.1 примерно на одном уровне, возможно, немного превосходя друг друга по каким-то отдельным критериям.

Но печально, что у LS даже примерные сроки выхода не озвучиваются. Кстати, в этом отличие подходов в разработке ЛС и Альто. Релизы ЛС — долгие, мощные с большим числом изменений, приносящие много новых возможностей, но делающие переход на новую версию тяжелым и болезненным. Мы в Альто старемся идти более короткими шагами, пусть изменения от версии к версии не такие значительные и объемные, но зато обновления получаются более простыми и легкими.

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

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

Итого: у каждой CMS, я думаю, есть свои и плюсы и минусы. Поэтому я бы посоветовал потратить время, установить их все и сравнить. И делать выводы.

Минусы — это грустно. Но враждебное отношение к кому/чему? К ЛС и поклонникам этого движка? Да Бог с Вами. Уж чего-чего, а враждебных высказываний и гадостей в адрес «конкурентов», чем грешат иные апологеты ЛС, я тут не встречал.

Klaus плохого не посоветует :)

Все верно, для версии 1.0 и для версии 1.1 конструкции отличаются

Сейчас кстати в 1,1 нет возможность задать выравнивание и размер

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

Так нагляднее для юзеров