Может не стоит привязываться к mysql...

Так я как раз и объясняю, что к мускулю никто и не привязывается. Наоборот, было немало исправлений в SQL (в основном, с подачи Liandr ), которые убирали специфические мускульные команды, чтоб это работало на постгрессе.

Явная привязка к мускулю осталась только в инсталляторе движка. Со временем и от этого избавимся, только надо какой-то мигратор попробовать подобрать. Я пока не смог. Боюсь, как бы тут не получилось как с ORM — долго подбирал, от самых известных до каких-то совсем непопулярных. Но, в итоге, кончилось тем, что пришлось писать реализацию полностью свою.

В общем, повторюсь: принципиальной ориентации (если не считать инсталлятора) по мускуль нет. Если где-то в движке вылезают несовместимые с постгрессом SQL-запросы, то это не от «заточенности», а исключительно потому, что недоглядели

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

Если делать человеческую карту сайта на Альто, то принцип, видимо, какой-то иной должен быть

Как сделать карту сайта для людей на Альто?

Написать плагин. А есть понимание, как она должна выглядеть?

Замените парсер текстов с Jevix на Qevix. Для этого в файле app/config/config.local.php надо добавить строку:

$config['module']['text']['parser'] = 'Qevix';

А версия php какая?

Да, под семеркой есть такая проблема. Вот этот коммит ее решает:
https://github.com/altocms/altocms/commit/dfcdc822e4cea23b6a042eefd2f2afaada14187c

Но есть багрепорт о том, что возникает другая проблема — с запоминанием юзера при авторизации. Надеюсь пофиксить в ближайшие дни, и если других проблем не обнаружится, то можно будет констатировать, что движок «PHP 7 Ready» )

Какая версия движка и какая версия php?

Проверил так: Скачал плагин, распаковал и залил его в папку common/plugins/selectelstorage, как сказано в его инструкции, активировал через админку, ошибок не получил. Работоспособность самого плагина не тестировал.

Опишите пошагово свои действия, чтоб понять, на каком этапе эта ошибка возникает

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

Да нет никакого погружения в «в дебри mysql». Но то, что все тестируется в первую очередь на MySQL — это верно. И, полагаю, вполне оправдано, т.к., как ни крути, но большинство все ж именно эту БД используют.

Что касается ORM, то эта фича в движке точно будет. В какой-то степени она уже есть, доставшись в наследство от ЛС, но мне эта наследованная реализация очень не нравится. Поэтому будет новый механизм ORM, больше похожий на то, как это сделано в yii, laravel, propel. Пока не могу сказать наверняка, но, возможно, уже в 1.2 появится.

Только ведь ORM — это не панацея. Во-первых, ORM не может покрыть абсолютно всей массы запросов к базе (это может быть 80% или даже 90%, но не 100%). Все равно будут запросы, которые требуют ручного тюннинга и обычного SQL. Во-вторых, какой-бы крутой ORM не использовался, все равно в итоге все транслируется в SQL. Т.е. по любому могут возникать SQL-запросы, который ненароком ломают совместимость с какой-то конкретной СУБД.

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

В версии 1.2 точно не планируется. И не могу обещать что непосредственно CKEditor будет непосредственно в «коробку» интегрирован. Все ж «идеальный» редактор — это выбор очень субъективный. Поэтому какой редактор не включи — всегда будут предложения включить что-то иное.

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

После отключения плагинов желательно обнулить весь кеш. Если делать вручную, то это очистка папки /_tmp

В обоих случаях rel=canonical должны иметь один URL. Раз он отличается, то это баг. А сайт используется на одном языке или он мультиязычный? Если язык используется один, то второй язык нужно отключить, и тогда языкового URL вида site.com/ru/ формироваться не будет

Возможно. Я видел упоминания, что WLW можно настраивать под конкретное API, но сам с WLW не работал, насколько там все кастомизируется — не знаю. Надо будет смотреть. Если знаете какие-то ресурсы про то, как работать со сторонними сайтами, накидайте ссылочек

В админке — Сайт / Оформление — выбираете нужный шаблон и кликаете по кнопке «Активировать»

А он идет в базовой поставке «из коробки». Просто активируйте его в админке

А поиск в закрытых блогах с учетом прав доступа не появится?

Скорее всего, появится, но пока не знаю наверняка.

Единый центр авторизации для мультидоменных сайтов?

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

можно ли как то проверить на существование аватарки и если её нет то отдать стандартную?

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

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

А в какой файл шаблона лучше всего вставить код

Лучше всего в «мастер-шаблон» (layout), от которого все остальные файлы шаблонов наследуются. Если это experience-simple, то для дефолтной темы это будет common/templates/skin/experience-simple/themes/default/layouts/default.tpl. Там перед вставкой верхних меню, например, можно:

        {* Строим менюшки *}
        <div class="container">
            <a href="?lang=en">EN</a>
            <a href="?lang=ru">RU</a>
        </div>
        {include file='commons/common.header_nav_pages.tpl'}
        {include file='commons/common.header_nav.tpl'}

Но а если пойти меньшей кровью, например, написать плагин, по типу как это реализовано в ВП?

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

Сама по себе переключалка языков — это всего лишь небольшая доработка шаблона. Можно добавить в шаблон примерно такой код:

<a href="?lang=en">EN</a>
<a href="?lang=ru">RU</a>

А в app/config/config.local.php задаете:

$config['lang']['allow'] = array('ru', 'en');   // какие языки доступны на сайте
$config['lang']['in_get'] = true; // проверка языка в GET-параметре: 'lang=ru'
$config['lang']['save'] = '1 year';  // сохранение языка в куках 1 год

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

Контент по выбранному языку при этом не фильтруется. Функционал, позволяющий фильтровать контент по языку будет реализован в следующей версии.