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

По задумке при обработке URL-запроса уровень конфига на разных этапах должен расти, достигая максимума в момент вывода на экран. И после некоторых ковыряний обнаружил, что в некоторых случаях уровень при выводе шаблона падал до LEVEL_ACTION.

Короче, баг это был. Теперь в шаблоне все будет работать корректно и без явного указания уровня конфига.

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

Тогда будет ли возможность настроить какой тип блогов создается при регистрации, если я отключу personal?

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

добавить автоматическое определение URL блога

Имеется ввиду, ЧПУ, как у топика?

altocms.ru/rss/ — не?

Немного не так, вот такой порядок:
— движок — /common/templates/language\ru.php
— приложение — /app/templates/language\ru.php
— скин — /common/templates/skin/<имя_скина>/settings/language/ru.php

А текстовки плагинов загружаются в свое пространство и не мешаются с общими.

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

Я так понял что логика все равно осталась зашитой на personal, open, close...

Нет, не совсем так. После долгих колебаний решено было оставить особую обработку блогов типа personal. Они по особой логике обрабатывались в ЛС, и эта логика передалась по наследству в ранние версии Альто. И решено было оставить ее и в этом релизе. Другое дело, что их можно выключать (если персональные блоги не нужны, и о чем часто просили, и даже специальные плагины писали для этого).

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

Плагин Ls присутствует в plagins.dat в самой первой строчке?

И, на всякий случай, уточню: plagins.dat сейчас находится в папке /app/plugins/

Да, это существенное замечание, т.к. я не мог совершенно никак проблему воспроизвести

Вот только что скачал свежий вордпресс — там в коробке три шаблона идет. И ничего, как-то справляются :)

на хороший дефолтный шаблон

Дело за малым — определиться, что есть «хороший». Мучаюсь этим вопросом уже не первый месяц

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

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

Спасибо большое за проделанную работу.

Да, на install смотреть не надо, установка сейчас однозначно под мускуль заточена. Да и вообще, есть еще немало «мускульных» мест в движке, которые нужно аккуратно адаптировать. Но нормальная и безусловная поддержка PostgreSQL — это одно из приоритетных направлений развития движка

Я думаю, у Вас не включен плагин Ls (плагин совместимости). Причем, он должен идти самым первым в списке подключенных плагинов

Я немного запутался, и уже не очень понимаю, к какому движку относится последний коммент :)

Если к Альто, то у нас есть автоматическое определение поддержки графических расширений PHP. Если даже вы не понимаете, что такое imagick и есть ли оно у вас на сервере, движок сам это поймет и будет его использовать. Либо не будет, если этого расширения нет. Но, в то же время, есть возможность явно указать, какое расширений использовать для обработки картинок.

Если к ЛС — им нужно менять или полностью переписывать класс работы с изображениями, чтобы обеспечить поддержку imagick. Думаю, рано или поздно они придут к этому. А прогресс у них хороший, это верно. И есть уверенность, что мы этому в какой-то степени поспособствовали ;)

Неужели нельзя упростить (сжать) скрипты хотя бы до 2-3 или 5?

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

Специально список не составляли, но где-то тут на сайте народ выкладывал списки совместимых плагинов

Должны быть минимальными, необходимыми для запуска php-скриптов. Обычно — 644, но для конкретного случая могут быть необходимы и другие права

fixed

отображаются анимированные без всяких imagick

Значит, они вообще не обрабатываются никак, т.е. просто загружаются и все. Если менять размер или кропать стандартными средствами GD — анимация умирает

Ошибки из логов в студию