Нашел причину проблем с картинками — из-за настроек веб-серва. У меня в качестве фронтэнда используется nginx, на бэкэнде Apache. Статика отдается напрямую через nginx:

<code>location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|mp3)$ {
root  /vhosts/site;
}</code>

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

Вы бы лучше продвинутую документацию сделали как на ЛС docs.livestreetcms.com/

Тогда бы многим разработчикам проще было переносить проекты, переделывать плагины или писать с нуля…

Хотя в блоге тоже что-то есть, но только если какие-то плюшки особые описывать, на которых внимание стоит акцентировать…

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

Он отвечает быстро на 20, а потом уходит в даун.
Лайвстрит уверен тоже отвечает на первые запросы быстро, а потом затыкается и отвечает крайне медленно отсюда и рост времени ответа.

loaddy.com/
P.s. Если добавите altocms.ru на этом сервисе к себе в домены, то не закрывайте публичный доступ. Дайте возможность тестировать другим. Если кто-то будет использовать сервис как ддос, то закройте.

На самом деле inplace-редакторов куча, то что предложила Alyona , vitalets.github.io/x-editable/demo-bs3.html, www.appelsiini.net/projects/jeditable/default.html, и т.д.

Любой из них можно прикрутить к Alto, но в чем будет бонус?

Плюс к этому, большинство этой красоты работает только с современными браузерами, так, что тут дело сугубо индивидуальное. — Мое мнение.

to Alyona а это не лучше будет? aloha-editor.org/index.php

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

Сразу предлагаю следующий патч для обхода этого механизма дабы дать взможность разработчикам шаблонов сразу видеть что у них получилось:
Package.entity.class.php:

    public function MakeSingle($sAsset, $aFileParams) {
        $sFile = $aFileParams['file'];
        if ($aFileParams['merge']) {
            $sSubdir = $this->_crc($sAsset . dirname($sFile));
        } else {
            $sSubdir = $this->_crc(dirname($sFile));
        }

        //Если дебагим (к примеру шаблоны) то нам незачем assets использовать
        if(defined('DEBUG') && (DEBUG == 1)){
            $sDestination = $aFileParams['asset'];
        } else {
            $sDestination = $this->Viewer_GetAssetDir() . $sSubdir . '/' . basename($sFile);
        }

        if (!$this->CheckDestination($sDestination)) {
            if ($sDestination = $this->PrepareFile($sFile, $sDestination)) {
                $this->AddLink($aFileParams['info']['extension'], F::File_Dir2Url($sDestination), $aFileParams);
            } else {
                F::SysWarning('Can not prepare asset file "' . $sFile . '"');
                return false;
            }
        } else {
            $this->AddLink($aFileParams['info']['extension'], F::File_Dir2Url($sDestination), $aFileParams);
        }
        return true;
    }

Для сообществ (например, livestreet.ru) эта вещь неочевидна, потому как те, у кого не хватает рейтинга, не могут писать посты в коллективные блоги. И для них персональный блог — единственная возможность написать пост.
Но если сообщество не тематическое, и пользователей больше двух-трёх сотен, то возникает ситуация, что персональный блог не защищён от нежелательных посетителей. Пользователи резонно жалуются: в своём персональном блоге я не могу ограничить доступ никому, не могу забанить, не могу запретить комментировать кому-то конкретному, не могу запретить читать. Отсюда конфликты.
В принципе вопросы кого пускать, а кого нет, было бы хорошо передать на усмотрение пользователям, но пока этого нет, можно использовать «подружиться», которое сейчас ни на что не влияет, как я понимаю.

Относительно персональных блогов было бы неплохо предусмотреть в «правах доступа к блогу» в пунктах «Кто может читать» и «Кто может комментировать» таких пользователей как «только друзья». Формально там есть, видимо, возможность ограничить доступ к персональному блогу через членство (проверить не могу, т.к. после редактирования сейчас всё заканчивается на SQL error...), но было бы логично, если бы пользователи подружившись получали бы доступ к персональному блогу, а прекратив дружбу, этого доступа лишались бы

Так и сейчас любой наследник LsObject может в своих методах обращаться к модулям:

$this->Topic_GetTopicsByFilter();

Этот вызов в текущей реализации отработает в любом компоненте — сущность, маппер и т.д. Или речь о чем-то другом?

Но дополню: если и внедрять подобную реализацию, то я бы предложил чуть-чуть иной подход, а именно вместо:

$this->modules->topic->getTopicsByFilter($aFilter,$iPage,$iPerPage,array('user','blog'));

реализовать что-нибудь типа:

E::$Modules->topic->getTopicsByFilter($aFilter,$iPage,$iPerPage,array('user','blog'));

Возможно, не так красиво, но есть важное преимущество: мы явно указываем, что не к свойству текущего объекта обращаемся, а именно к модулю. И если даже какой-то новичок программер, не въехав в нюансы, создаст экшен в котором по ему ведомой логике объявит свойство $modules — он напрочь сломает вашу реализацию, а в моем варианте все будет работать.

Если без холивара, то так сложилось исторически. Дело было давно на одном большом проекте (сайт+форумы), тогда mysql хоть и работал быстро, но периодически затыкался из-за особенностей myisam. Перевод на innodb в целом проблем не решило. К тому же у mysql каким-то невообразимым образом иногда слетали индексы. Переход на postgres в те далёкие времена не дал схожей производительности, но зато он работал стабильно, предсказуемо и без необъяснимых затыков. К тому же от версии к версии ситуация с производительностью быстро менялась в сторону улучшения. Потом освоились с полнотекстовым поиском и пр. и про mysql забыли как страшный сон.
Сейчас периодически работаю с CMS, заточенными на mysql, и до сих пор не понимаю, почему ещё оно живо. Хотя вру — «спасибо» за это хостерам, следующим классическому LAMP.

В общем, я первый в очереди на тестирование под PostgreSQL.

гифки есть и тяжелые, и их много. Хотя старался урезать количество гифок на одной странице до минимума — сейчас их 7.

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

Вот, спасибо!!! Действительно нужный функционал. А скажите в 1-ой ветке будет решена давняя проблема с загружаемыми картинками, которые потом нельзя удалить из интерфейса? Хороший вариант решения представила Alyona

Очень похоже на БЭМ, не так-ли?

Боюсь, коротким комментом тут не получится отделаться, но для начала поясню хотя бы ключевые моменты.

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

Функциональные

1) Самое большое — это замена LS-блоков виджетами. Что за собой повлекло изменение в наименовании папок и файлов шаблонов и синтаксиса вставки виджетов в шаблоны (на самом деле изменений больше, но тут я с точки зрения шаблонов описываю). Львиная доля функционала плагина совместимости — обеспечить работу со старыми LS-блоками, как с родными Alto-виджетами. В ближайшее время я планирую серию статей про виджеты, где постараюсь все про них описать, в т.ч. и с точки зрения разработки шаблонов.

2) В Alto CMS есть функционал из коробки, отсутствующий в LS, который надо предусмотреть. Например, отказ от жесткого и предопределенного разделения на «просто топики», «топики-фотосеты», «топики-опросы», «топики-ссылки». Фотосеты, опросы и ссылки могут добавляться к любому топку (но возможность их добавления может включаться/выключаться в админке). Плюс — дополнительные поля, которые так же в админке могут задаваться.

3) Есть так же возможность редактирования комментов. По сравнению со всем тем, что выше написано, вроде мелочь, но тоже надо учесть это в верстке.

В принципе, все эти изменения понятны и можно все детально описать.

Структурные

А вот тут все непросто. Потому что на сегодняшний день уже есть, как минимум, три стиля создания шаблонов, у которых разная внутренняя организация, структура папок и принцип именования файлов:

1) Стиль «Олдскул» — нынешний LS-стиль, реализованный в версии 1.0.х. Практически все рабочие плагины для ЛС 1.0 заточены под этот стиль. Но если судить по изменения в гитхабе ЛС, есть решение от него отказаться.

2) Стиль «ЛС-новый» — тот стиль, котрый активно разрабатывается в ЛС сейчас. Это — использование принципов наследования, изменение структуры папок и принципов именования файлов. В стиле «ЛС-новый» в значительной мере реализуются идеи, которые я пытался продвинуть в ЛС примерно год назад.

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

Итак, ключевой вопрос: если говорить об адаптации шаблонов под Альто, то для начала надо решить — в каком стиле проводить эту адаптацию?

Золотой Вы человек. Все как я и хотел. Только вот получается при обновление движка все затираться будет. А еще можно все токи единственное поле из набора сделать через шаблон.

Вопрос снимается:
в файлике /config/widgets.php добавляем соответствующий виджет (можно просто скопировать одного из предшественников), вписываем например:
$config['widgets'][] = array(
'name' => 'widgets/widget.page.tpl',
'group' => 'right',
'priority' => 100,
'action' => array(
'page',
),
);

после этого создаем шаблончик /templates/skin/fortune/blocks/block.page.tpl (в других темплейтах, соответственно будут свои) и пишем в этот файл свое содержимое — то, которое потребуется…

Спасибо, Вадим, за подсказку… ))

Чтобы виджеты («блоки» в терминологии ЛС) выводились на статических страницах, нужно в определении этих виджетов указать путь (или экшен) для показа. Например, в опцию 'action' добавить 'page':

$config['widgets'][] = array(
    // тут разные опции виджета
    'action' => array(
        'index',
        'community',
        '...',
        'page', // чтобы это виджет показывался, когда вызывается экшен 'page'
    ),
);

Добрый день, да пример есть тут livestreet.ru/blog/dev_documentation/14894.html

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

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

В общем, т.к. из команды ЛС никого не было, я отдувался и за ЛС, и за Альто. :)