Alto CMS 1.2 — планы по разработке

Решил анонсировать некоторые фичи, которые ожидаются в версии 1.2 (тем более, что меня часто в последнее время спрашивают о некоторых из них). В новой версии будет два основных направления: улучшение мультиязычности и REST API. Хотя только этим, конечно, улучшения не ограничатся.

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

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

Что еще планируется:
  • Наследование скинов. Сейчас, если вы хотите на базе существующего скина создать свой, то приходится полностью копировать исходный скин и уже в нем что-то менять. Давно напрашивается механизм наследования, когда вы указываете родителя и в дочерний скин добавляете только те файлы, которые нужно изменить.
  • Кастомизация среды исполнения. Среда исполнения в данном контексте — это создание нескольких наборов «конфигурация + скин + активные плагины». И, в зависимости от условий, можно будет подключать тот или иной набор.
  • Улучшенная работа с ассетами: как минимум, будет добавлена поддержка атрибутов async и defer для js-файлов.
  • Будут и другие, может, менее значимые, но полезные улучшения и исправления, как например, прикрепление топиков, добавление extra-данных для таких сущностей, как пользователи, комментарии и блоги (сейчас они есть только у топиков), которые позволяют хранить любую дополнительную информацию без возможности поиска и фильтрации по ней и т.д., и т.п.
Возможно (пока еще нет окончательного решения), будет изменен механизм создания топиков. Сейчас сначала заполняется форма со всеми данными, а потом уже сам топик пишется в базу. Есть желание принципиально изменить этот подход: сначала создавать в базе черновик, а потом уже открывать форму редактирования топика.

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

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

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

Предвижу, что у кого-то могут возникнуть вопросы: «Как? Еще 1.1 до конца не отшлифовали, а уже 1.2 начинаете?». Да, начинаем.

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

Во-вторых, несмотря ни на что, надо двигаться вперед. Застой убивает.

Похожие статьи

  • Релиз 1.1.19 и новые подробности про версию 1.2
    Вышел релиз движка 1.1.19 Чего-то особенного он не принес, это, в основном, множественные багфиксы. За исключением одной детали — в качестве парсера текстов по умолчанию теперь используется Qevix. Поэтому если вы...
  • [dev] ActiveRecord в Alto CMS v.1.2. Часть 1
    По сложившейся традиции пишу о наиболее интересных и важных нововведениях в движке еще до официального релиза. Не помню, возможно, писал уже о том, что я несколько раз подступал к реализации ActiveRecord в Альто....
  • Релиз версии 1.0.7
    С момента выхода релиза 1.0 вышло уже несколько обновлений (последнее — версия 1.0.6). Как правило, в обновлениях исправлялись какие-то мелкие ошибки, делались небольшие улучшения, и не было необходимости как-то...
  • Плагин miniMarket 0.4.0. Инсайд. Часть вторая
    1. Плагин miniMarket 0.4.0. Инсайд. Часть первая 2. Плагин miniMarket 0.4.0. Инсайд. Часть вторая В первой статье, посвященной анонсу плагина miniMarket версии 0.4.0, я постарался рассказать о новом шаблоне и его...

52 комментария

0
А поиск в закрытых блогах с учетом прав доступа не появится?
Единый центр авторизации для мультидоменных сайтов?
0
А поиск в закрытых блогах с учетом прав доступа не появится?
Скорее всего, появится, но пока не знаю наверняка.

Единый центр авторизации для мультидоменных сайтов?
Сразу нет. Но есть соображения, как это сделать как раз с помощью API. Общая схема такая: один сайт является основным, а остальные — ведомые, с точки зрения авторизации. И взаимодействие между ними будет через API.
+1
Отличные новости! Всё такое вкусное! :-)
0
Буду по-любому ждать!
0
И возможность загрузки на сайт непосредственно самих МП3 файлов тоже очень нужна. Нужен плеер по тпу как в ВП.
0
Почему mp3? С точки зрения оптимизации размера файлов при соблюдении качества я лично предпочёл бы ogg vorbis, да и flac не помешал бы с opus. Зачем привязываться к mp3?
Некисло бы возможность загрузки файлов нечто под названием audio с неограниченными подкатегориями и выводом этого добра плеером.
+1
0
опа!
0
пишет при активации

Ошибка:

Для работы этого плагина необходим активированный плагин Multiplefileupload

Где его взять-то Multiplefileupload?
0
А он вроде платный )
0
где взять то его?
0
Все, увидел! 300 рублей — это условно платный. Почти бесплатный.
0
Что он делает? Оборачивает ссылку на файл в тег video/audio?
0
Обновил описание.
+2
Можно ли в будущем сделать чтоб альто работал с Windows Live Writer через API
+2
Возможно. Я видел упоминания, что WLW можно настраивать под конкретное API, но сам с WLW не работал, насколько там все кастомизируется — не знаю. Надо будет смотреть. Если знаете какие-то ресурсы про то, как работать со сторонними сайтами, накидайте ссылочек
0
Это просто замечательно!)) Ждем с нетерпением
+1
Очень хотелось бы добавить еще CKEditor в качестве редактора, ибо tinyMCE даже в последней версии не радует. CK сейчас интегрирован в Drupal и на мой взгляд это самый адекватный текстовый редактор. Поэтому хотелось бы узнать, планируется ли такая интеграция?
0
В версии 1.2 точно не планируется. И не могу обещать что непосредственно CKEditor будет непосредственно в «коробку» интегрирован. Все ж «идеальный» редактор — это выбор очень субъективный. Поэтому какой редактор не включи — всегда будут предложения включить что-то иное.

Но вот в каком направлении работа точно будет вестись — так это более четкое абстрагирование используемых редакторов от самого движка. Должен быть простой механизм, позволяющий встраивать любой редактор. Пока это не так просто делается, но работать в этом направлении точно будем.
0
А как там с postgresql? А nginx+php-fpm?
0
на nginx+php-fpm работает «изкаропки»
0
Хорошо, проверю )
А postgresql? Очень интересно!
0
Где-то здесь есть тема с похожим обсуждением. Есть специфичные для mysql запросы. Если их переписать, то будет ок
0
У меня в продакшене работает собственная модификация под PostgreSQL. Раньше я размещал патчи и схемы для постгреса, но потом перестал.
К великому сожалению, авторы всё глубже и глубже уходят в дебри mysql.
В идеале хотелось бы иметь в движке DBAL (как PhpBB) или бы вообще ORM, а то приходится пачками переписывать запросы, что при отсутствии документации даёт некоторую вероятность ошибки. Вроде этого
-                  AND (m.type & (?d | ?d | ?d))
+                  AND (m.type::int & (?d::int | ?d::int | ?d::int))::boolean

P.S.
Нашел баг — при редактировании комментария, & превращается в & #38;
Отредактирован:
0
Спасибо за ответ. Жаль, если всё так, как говорите. Искренне не понимаю, зачем привязываться к mysql... Придётся видимо таки django использовать — оно даже к лучшему.
0
Да нет никакого погружения в «в дебри mysql». Но то, что все тестируется в первую очередь на MySQL — это верно. И, полагаю, вполне оправдано, т.к., как ни крути, но большинство все ж именно эту БД используют.

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

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

Отсюда вывод — только тестирование и фидбэк решает эту проблему, иначе никак. Кстати, в следующем месяце думаю тестовый демо-сайт на постгресс перевести.
0
Спасибо за подробное объяснение.
Понимаю, что mysql — приоритет (исторически сложилось в вебе), однако не понимаю, почему сейчас это актуально. То, что у хостеров есть всегда — так у нормальных хостеров есть и posgresql всегда. К тому же, vps стоят от 200 рублей... А навесить ту же vestacp — пара команд.
Я к тому, что... Может не стоит привязываться к mysql (mariadb, уж скорей).
Уж очень интересно получается — nginx+php-fpm+postgresql.
0
Может не стоит привязываться к mysql...
Так я как раз и объясняю, что к мускулю никто и не привязывается. Наоборот, было немало исправлений в SQL (в основном, с подачи Liandr ), которые убирали специфические мускульные команды, чтоб это работало на постгрессе.

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

В общем, повторюсь: принципиальной ориентации (если не считать инсталлятора) по мускуль нет. Если где-то в движке вылезают несовместимые с постгрессом SQL-запросы, то это не от «заточенности», а исключительно потому, что недоглядели
0
Вот ей богу постгрес должен быть на последнем месте по приоритету в данной cms. От того что он начнет поддерживаться из коробки никому кроме пары человек лучше не станет. Зато остальным станет хуже от того что вместо исправления ошибок у них теперь (после некоторых событий) любимая субд всех госпредприятий поддерживается. Ну круто, чо.
Отредактирован:
0
Зато в постгресс дблинки есть, а в мускуле* их нет... Табличку с юзерами можно было бы вынести в отдельную базу...Единая база авторизации для мулитидоменного сайта...
Насчет госпредприятий не понял...Откуда дровишки? Постгресс отвратно работает с 1С (если его ради этого на госпредприятия ставят), и вообще.. у нас например стоят Оракл и MS SQL постгресса нету вообще..

* Да, я в курсе насчет потенциальной возможности симулировать дблинки в мускуле.. но это все таки не то...
Отредактирован:
0
Дровишки непосредственно из. Его и так активно юзали, а как оракл некоторое время назад стал внезапно неправославным, один постгрес теперь только и пихают везде.
Понятно что в нем есть много всего, но обычным пользователям это не нужно. Даже я уже смирился. С MySQL вполне можно жить. Понятный и рабочий инструмент.
0
Скорей 1С коряво работает с постгресс )
Кажется 1С использовала свой механизм залочивания вместо стандартных постгресс... И ещё чего-то до кучи... Честно, так давно было, не помню.
Помню, что ржали долго над 1С...
А для обычного пользователя от использования постгресс не изменится ничего. И это тоже вполне себе понятный прекрасно работающий инструмент с большими возможностями.
А оракл и так неправославный, равно как и mssql ))
Отредактирован:
0
Вроде этого
-                  AND (m.type & (?d | ?d | ?d))
+                  AND (m.type::int & (?d::int | ?d::int | ?d::int))::boolean

Нашел, где используется эта конструкция. Удивлен, что постгресс не понимает битовых выражений. И данный вариант замены, конечно, тоже не годится, т.к. это получается чисто постгрессовская фича. Значит, надо выражение переписывать так, чтоб правильно отрабатывалась на разных ДБ-движках.

Нашел баг — при редактировании комментария, & превращается в & #38;
Баг известен, будет устранен в 1.2 (чтоб без костылей работало, надо исходник текста коммента сохранять, а нынешней структуре БД просто некуда).

ЗЫ. А ORM как ActiveRecord в 1.2 будет, вопрос решенный.
0
Все требует настройки. Сразу готовьте напильник.
0
Я скорей выберу другой инструмент. В виде другой CMS/CMF...
+1
Если есть готовая CMS, которая стопудово удовлетворяет всем вашим запросам безо всяких допилок, где все, что хочется, получаете в один клик, то тут и думать нечего — брать надо ее. Вот только на практике такое очень редко бывает. И, конечно, CMF и «чистые» фреймворки под это не подходят, допилка там нужна просто по определению.
0
Практика показывает, что допилка нужна всегда.
Главное — в начале выбрать правильно, чтобы потом не было мучительно больно )
0
Давно напрашивается механизм наследования, когда вы указываете родителя и в дочерний скин добавляете только те файлы, которые нужно изменить.
Ещё есть проблема с переопределением файлов, которые инклюдятся в другие файлы с помощью тега {include file=""}. В этом случае придётся переопределять родительский шаблон, в котором исправлять путь в {include}
0
пытался прикрутить плагин от LS для загрузки\удаления файлов из хранилища селектела (это типа как S3 у амазона), но ничего не заработало даже со включеным плагином, обеспечивающим совместимость.
0
Под вопросы есть отдельный блог: http://altocms.ru/blog/questions/
При этом лучше писать название плагина или ссылку на него. Ну и да, не всё переносится с лс со 100-процентной работоспособностью. В зависимости от каждого конкретного плагина.
0
Для меня возможность постить контент через апи — крайне важная новость. Сейчас добавляем посты напрямую в базу.
Не нашел когда ожидать версию 1.2, можно узнать хотябы примерные сроки?
0
Очень жду категории для блогов! Вроде мелкая фича, но если она появится то Atlocms будет идеальным для моего проекта!
0
а это http://altocms.ru/addons/item/92/ не то?
+1
Неа, во-первых в модуле баг с задвоением виджетов, а во вторых категории указываются только в админке
0
Категории отображаются нормально, а с задвоением виджетов вроде есть решение тут. Для меня основная загвоздка — в подкатегориях. Блогов много и в категориях тесновато, а подкатегорий нет.
0
Что там слышно об версии 1.2? Когда она планируется?

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

Когда будет это реализовано, или возможно уже есть какие-то наработки, тогда дайте знать=)
+1
В дев-версии этого еще нет. Появится, я полагаю, не раньше, чем через месяц
0
Еще вопрос, а как именно будет реализована мультиязычность? Интересует больше формирование ссылок: site.com/ru/123.html или ru.site.com/123.html

Просто сейчас хочу создать 2 языка. Один будет использоваться сейчас, а второй после апдейта CMS (добавления мультиязычности).

Или же, посоветуйте, как лучше сейчас организовать 2 языка на сайте? На поддоменах или же ждать обновления CMS? =)
0
По умолчанию языковые ссылки формируются так: site.com/ru/123.html
Но если нужно, то, скорее всего, их можно будет, при желании, сформировать и на поддоменах ru.site.com/123.html
0
А как сделать, чтобы например, русская версия сайта вся была с урл site.com/ru/123.html, а английская просто site.com/123.html Или это не будет предусмотрено?
0
Т.е. для одной версии язык явно указывать, а для другой нет? Хм, не уверен, что это можно будет сделать, т.к. получается, что для разных языков нужно использовать разную логику формирования URL, что весьма проблематично
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.