Если нужно, чтобы везде добавлялось /ru, и при этом сейчас на сайте используется только один язык, то самый простой вариант такой: создать в корне сайта папку /ru/ и движок установить в этой папке. И все — без всяких дополнительных настроек получите желаемое. А из корня сайта прямо средствами вебсервера настроить редирект в папку /ru (если используется Apache, то это в файле .htaccess делается).

Со временем, когда Вы будете готовы запустить мультиязычную версию сайта, то в эту новую версию с соответствующими настройками Вы можете установить уже в корень, и пути типа /ru/ и /en/ у Вас уже будут виртуальными и отрабатываться роутером движка.

Вот тут есть о настройках для загрузки изображений, в т.ч. и по анимации: http://altocms.ru/1018.html

Ну, и проверил, на всякий случай: http://demo.altocms.com/new/44.html — работает

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

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

Еще раз: если задаете УРЛ static.ru, то файлы надо класть в корень этого хоста. Причем, у движка должен быть файловый доступ к этой корневой директории. А вы кладете в одно место, а забирать хотите из другого. А откуда они там возьмутся?

Например, если у хоста static.ru корневая директория /var/sites/user/data/static.ru/www/, то именно этот путь и надо указывать $config['path']['runtime']['dir']. Ну и, конечно, у аккаунта, под которым работает движок на сервере, должна быть возможность записи по этому пути.

И тогда все замечательно будет работать

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

Если я правильно понял, то хочется:
1) Сменить общий путь
2) Чтоб все стили были в одной подпапке, а все скрипты в другой
3) Чтоб не было в пути непонятных подпапок /46d33a5e/ (т.е. чтоб можно было задавать весь путь прямо до имени файла )

Я не очень понимаю, конечно, а зачем оно вообще все это нужно и ради чего тратится столько усилий, но скажу, что реализовать все это в комплексе просто настройками движка не получится в принципе. С помощью ковыряний конфига можно выполнить можно только п.1, но складываться все будет все равно в подпапку .../assets/.

а начать искоренять зло начиная с корня...

Если прямо с корня, то не уверен, что получится сохранить совместимость. Делать прям двойное ядро — плохое решение. Тогда уж лучше запускать ветку 2.+, в которой можно не заморачиваться с совместимостью, а делать сразу все правильно, насколько это возможно, по канонам, паттернам и все такое. Но это стопудово будет долгая история. Кто готов в это вписаться?

Если есть конкретные предложения — пишите, обсудим. Но лучше отдельным топиком.

Если конкретно про Doctrine и Eloquent говорить, то Doctrine отпал сразу, как чрезмерно тяжелый и излишне навороченный. А к Eloquent присматривался и подступал несколько раз. Не все мне в нем нравится, но в целом было желание просто взять и его прикрутить (или, например, Propel). Но не придумал, как это сделать без танцев с бубнами.

Чего хотелось:
1) Чтоб можно было сохранить совместимость с нынешними классами — Entity, Module и Mapper, но при этом использовать синтаксис ActiveRecords а-ля Eloquent или Yii
2) Чтоб можно было использовать просто построитель запросов, как в Yii
3) И чтоб при этом сохранялась возможность задавать SQL-запросы, как оно сейчас делается в движке

Ни с одним из сторонних ORM-движков не получалось этого реализовать.

Ошибка возникает из-за того, что движок считает первую часть адреса «ru/» обозначением языка, поэтому роутер отбрасывает ее и дальше работает с оставшейся частью, а она уже не совпадает с маской URL'а.

В общем, чтоб нужная вам схема заработала нужно в app/config/config.local.php добавить строку:

$config['lang']['in_url'] = false;

Упс, есть косяк. Отвыкаю уже писать под PHP 5.3. Под PHP 5.4 и выше этой ошибки нет

Вот фикс: https://github.com/altocms/altocms/commit/222c4ff16229e80f8ba251f36073634c543bf35f

Не уверен, что мы говорим об одном и том же. Поэтому кое-что поясню.

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

Движок все это раскиданное хозяйство обрабатывает и собирает в одну рантайм-папку, откуда уже и подключает в итоговый HTML-код страниц. По умолчанию это папка /_run/assets/. Ну, в общем-то да, можно ее назвать кешем для статики.

При желании эту папку с подключаемой статикой можно изменить, для этого меняется параметр $config['path']['runtime']['dir']. Чтоб движок знал, по какому URL эта папка доступна (т.е. какие пути указывать для подключаемых в HTML файлов), задается соответствующий параметр $config['path']['runtime']['url'].

Подчеркну — в эту рантайм-папку ничего вручную переносить не надо, движок сам все перенесет. Исходные js/css тоже трогать не надо — движок сам будет их брать из прежних исходников и класть в новое место.

Поэтому, если задается новое место для рантайм-ассетов (кеш для статики), то удалить можно только содержимое старой папки /_run/assets/, больше ничего удалять не нужно.

Я ясно излагаю?

остался вопрос, в файле assets.php как правильно переподключить файлы для статики, сейчас стандарт
'___path.skin.dir___/assets/css/posts.css',

Вопрос не очень понятен, т.к. это путь, который указывает ОТКУДА брать файлы. Эти пути ведь не меняются. Меняется только путь КУДА их класть уже обработанные, а это задается в $config['path']['runtime']['dir'].

то как быть с кешем

О каком кеше в данном случае речь?

Файл с таким именем используется в шаблоне Категории. Попробуйте очистить папку _tmp/templates

Вот уже второй человек за последнее время пишет, что не создается таблица session. Но почему такое происходит — я не могу понять. Провел несколько пробных установок «с нуля» и под Виндой, и под Линуксом — все установилось и работает без проблем. Видимо, есть какой-то нюанс при установке, только вот какой?

Установил с нуля в подпапку, движок при установке прописал такие значения (все автоматом, ничего руками не трогал, я тут только имя домена заменил):

$config['path']['root']['url'] = 'http://site.com/subdir/';
$config['path']['root']['dir'] = ALTO_DIR . '/';
$config['path']['offset_request_url'] = '1';
$config['path']['runtime']['url'] = '/subdir/_run/';
$config['path']['runtime']['dir'] = '/var/www/user/data/www/site.com/subdir/_run/';

Все запустилось и прекрасно работает. Вы точно последнюю версию движка ставите?

В том-то и дело, что я не понимаю, в чем проблема. Вот описание самого Гугла про мультиязычное таргетирование: https://support.google.com/webmasters/answer/189077?hl=ru

В движке все сделано именно так. Где там могут понадобиться запятые — мне непонятно.

Теперь (в версии плагина 1.1.13) — можно (порядок сортировки задается при создании/редактировании категории). Только плагин пока на гитхабе, в каталоге позже обновлю

Исправлено

Обновил плагин Категории (пока только на гитхабе, в каталоге обновлю чуть позже).

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

https://github.com/altocms/alto-plugin-categories/releases/tag/1.1.13

Дело в том, что замечания «что-то где-то почему-то неправильно» — это вот не работает. Работает так: «Гугл говорит, что вот в этом коде в таком-то месте надо поставить запятую»