Выложен в публичный доступ репозитарий Альто 2.0

Кому это интересно — выложил в паблик репо второй версии: https://github.com/altocms/altocms2

ВНИМАНИЕ: это НЕ релиз, НЕ выход новой версии, это вообще НЕ рабочая версия, это репозитарий, в котором в настоящее время ведется разработка. Это только начало обновления движка, много чего еще нужно доделать там. Как я уже говорил, есть наработки, которые сейчас выполнены в виде плагинов и просто хардкодных хаков, и я постепенно их внедряю в движок. Я б, конечно, не стал в таком виде выкладывать, поковырялся бы еще, но раз публика просит...

Что можно сейчас увидеть в репо:
1) Изменена структура папок. В первую очередь это сделано в целях повышения безопасности. Почти весь движок убран в папку /protected — это папка, к которой нет доступа снаружи. Если сайт работает под Apache, то нет необходимости раскидывать запрещающие файлы .htaccess по разным папкам, достаточно положить его в /protected. Если у вас все крутится под Nginx, то в конфиге закрываете доступ извне только к этой папке. При желании ее вообще можно вынести за пределы корневой папки сайта.

2) Добавлена поддержка Composer. В движке пока еще осталось несколько библиотек, у которых нет по-человечески оформленных пакетов, и лежат они по прежнему в /protected/engine/libs, но все остальные сторонние библиотеки вынесены в /protected/vendor и могут обновляться композером. Обратите внимание, что общий пакет зависимостей собирается из нескольких файлов:
/protected/engine/composer.engine.json
/protected/common/composer.common.json
/protected/app/composer.app.json
/protected/app/plugins/composer.plugins.json

При этом два первых файла являются обязательными, а два других — опциональными (т.е. их может не быть). При установке плагинов их зависимости должны прописываться в файл composer.plugins.json. А если вам при разработке сайта потребовались какие-то свои зависимости, то вы можете их прописать в composer.app.json. Что это дает:
а) легко можно обновлять все зависимости одной командой
б) исключается дублирование, когда, например, разным плагинам нужна одна и та же библиотека
в) если вдруг возникает конфликт версий, то Composer это обнаружит при обновлении

3) Классы ядра переведены на неймспейсы. В перспективе, конечно, надо все классы на неймспейсы переводить

Что еще из более-менее крупного:
* Удалены костыли «совместимости», возможно, где-то следы еще остались, будут подчищаться по мере обнаружения.
* В конфиге можно задать несколько баз данных и в запросах указывать, к какой базе идет обращение. Причем, фактически база может быть и одна, но разные наборы таблиц с разными префиксами
* Теги — универсальная сущность, а не только для топиков
* Хеширование паролей — через password_hash()
* Меню и виджеты из основного конфига убраны, теперь это исключительно в настройках шаблона задается

В планах так же роутинг сделать на базе https://github.com/auraphp/Aura.Router/tree/3.x
А кеширование на базе http://www.phpfastcache.com/

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

  • Еще немного о ближайших планах по развитию движка
    Мне пишут в личку и спрашивают о подробностях. Понимаю, люди хотят бОльшей определенности. Решил вот написать чуть больше о своих планах. Уж не знаю, прибавит это определенности или нет, но, возможно, кому-то это...

19 комментариев

0
Измените инструкцию к установке. При заходе на сайт/install пишет «Пока полноценной инсталляции нет»
Залил бд, прописал данные в конфиге, вот ошибка

E_WARNING [2] require(/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/../xxtea/xxtea/xxtea.php): failed to open stream: No such file or directory
See details in error.logE_WARNING [2] require(/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/../xxtea/xxtea/xxtea.php): failed to open stream: No such file or directory (/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/autoload_real.php on line 66) Fatal error: require(): Failed opening required '/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/../xxtea/xxtea/xxtea.php' (include_path='.:/usr/share/php') in /home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/autoload_real.php on line 66
E_COMPILE_ERROR [64] require(): Failed opening required '/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/../xxtea/xxtea/xxtea.php' (include_path='.:/usr/share/php')
See details in error.logE_COMPILE_ERROR [64] require(): Failed opening required '/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/../xxtea/xxtea/xxtea.php' (include_path='.:/usr/share/php') (/home/r/rangroup/medivh.ru/public_html/protected/vendor/composer/autoload_real.php on line 66)
0
Предупреждаю сразу — это еще НЕ рабочая версия
0
Я не слепой, видел, я указал на возможный исход.
0
Нашел. Сорри. Честно думал, что поставить пока нельзя...
0
Впрочем, не исключено, что Readme.RU.txt просто копированный файл из прежних версий и тут не катит...
0
...
Отредактирован:
0
Долго слежу за альтоцмс, еще с первого анонса на сайте лайвстрита. Мне нравился подход админов к вопросу, тоесть цмска для людей. Шаблоны, возможности все готово бери и работай.
Но вот этот «релиз» очень печалит. Тут некоторые подгоняли админа, мол выкладывай что есть, а он возьми и выложи нерабочую цмс с кучей косяков и сомнительными улучшениями. Браво все молодцы и админ не промах ;) выпросили получите и распишитесь не пойми что. Я ждал выхода новой версии, чтобы определиться и начать работу над сайтом, зато теперь понятно, в ближайшем будущем рабочей wvc не ждите.
Не понимаю людей которые тут пишут, что нет альтернатив. А как же модекс? Вот этот сайт полностью на нем https://modx.pro/ и это не реклама. И чего тут нет что есть здесь? Конечно надо соображать и изучать, но это ласт свои плоды.
Сейчас начнется, не нравится проходи мимо, мы тут все любим альтоцмс, а ты кто такой? Поэтому скажу просто, это мое личное имхо.
+2
вот скажите, сколько надо времени, что бы допилить modx для создания сообщества, то есть наличие того функционала, что у Альто из коробки? и сколько надо в это положить средств не программисту?
Отредактирован:
0
Я, как программист с многолетним стажем, скажу коротко, но ёмко: MODX — раздутое, не поддающееся сопровождению говно.
0
Реализовать такой функционал на modx будет сложно/долго без соотв. ресурсов — знаний/денег. Вообще в тему про modx, еще на livestreet предлагали совместить modx и ls http://livestreet.ru/blog/12815.html очень интересное решение предлагал автор.
0
Имхо такое сращивание просто..ненадо...
Отредактирован:
+3
Но вот этот «релиз» очень печалит. Тут некоторые подгоняли админа, мол выкладывай что есть, а он возьми и выложи нерабочую цмс с кучей косяков и сомнительными улучшениями
Возможно, я не вполне четко описал в топике, что это лишь рабочий репозитарий. Сейчас добавил, выделив жирным — так понятнее?
+2
Возможно, я не вполне четко описал в топике
Похоже, что каждый видит то, что хочет или способен увидеть.
что это лишь рабочий репозитарий
Успехов в работе, Вадим. Мы по прежнему с Вами (и с АльтоCMS).
+1
И кстати, именно выложенный репозиторий второй версии движка, успокоил меня в плане продолжения работы над своим проектом особо не зацикливаясь на архитектуре обеих веток. Лично для меня переход/обновление обойдется малыми жертвами. А этот вопрос, признаться, до вчерашнего дня лишал меня мира душевного.
0
aVadim почему юзается все тот же забитый паттерн Singlton, который уже является антипатерном в тенденции текущего статуса php. Так же по текущей тенденции все системы и проекты стараются начать плавный переход на php7, который показывает весьма более приятные результаты как по скорости, так и по возможностям разработки и оптимизации.

В системе создается свой велосипед, как вариант существуют микрофреймворки simfony 4, slim framework, на случай если нет конкретного желания тянуть laravel с его не слабой абстракцией. Указанные фреймворки поддерживают систему адаптеров(кеширование, бд), совместимость с PSR-7, так же Роутинг.

Мое личное суждение, не пинайте. Сам пользуюсь альто, нет желания чтобы система ушла как LiveStreet с его мусором и дырками, а так же весьма сложной поддержкой со временем.
0
Сначала отвечу про php7 — у меня сейчас несколько проектов работает на текущей версии Альто в конфигурации nginx+php7. Для новой версии минимум php 5.6 значится не потому, что под семеркой не будет работать, а просто потому, что фичи семерки в ней не используются. Но сам код отлично крутится под php7.

Насчет синглтонов вопрос интересный, но несколько размытый, т.к. не очень понятно, о каких именно компонентах идет речь. Роутер в движке по любому один. Конфигуратор — тоже. Так почему они не могут быть синглтонами? Кстати в том же Ларавеле механизм фасадов реализует доступ к конкретным одиночным экземпларам классов в сервис-контейнере. Формально это, разумеется, не синглтон, но фактически реализует ту же идею — есть классы, у которых в приложении создается только по одному экземпляру объектов.

Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).

C Simfony 4 не работал, не знаю, что там и как, но несколько проектов на Slim сделал. И в одном из проектов, стати, на Slim посадил ларавеловский Eloquent ORM. Так что если вдруг сложилось впечатление, что я не знаю современных движков — это не так. ))) Знаю, пробую на практике, смотрю, что хорошего можно из них взять в Альто.

Нормальный роутинг обязательно будет (правда, вопрос остается — старый лайвстритовский роутинг оставлять? или ну его?). А про остальное надо говорить более конкретно — мол, вот такой-то компонент я предлагаю реализовать так-то. Будем обсуждать.

Могу только добавить, что мне нравится в Альто разделение классической модели на составные части — есть сущность, которая хранит свойства модели, и есть модуль, которые содержит в себе методы обработки модели. В работе с Eloquent ORM прям очень напрягает то, что там все это в одной куче. Но это может быть мое чисто субъективное отношение
0
Сначала отвечу про php7 — у меня сейчас несколько проектов работает на текущей версии Альто в конфигурации nginx+php7. Для новой версии минимум php 5.6 значится не потому, что под семеркой не будет работать, а просто потому, что фичи семерки в ней не используются. Но сам код отлично крутится под php7.


У меня имеется проект на альто под php 7.1 и работает он весьма плачевно, пришлось достаточно сильно изменить конфигурацию, а так же решить вопрос с полифилом под mbstring библиотеку. Главная страница админки с тестированием под php 7.1 даже не отображается, работает только левое меню и остальные функции.



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

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

Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).
Насчет синглтона понятия давно размытые, но я привык считать его антипаттерном из-за того, что еще со времен пхп 4, когда этот паттерн стал чертовский модным, многие люди не правильно поняли парадигму SOLID, а конкретно «Single Responsibility Principle». Паттерн синглтона очень скверный и сложный в реализации правильно, он усложняет юнит тестирование, лишает смысла «принцип единой ответсвенности» ввиду того, что он обязан следить за самим объектом синглтона, а так же за тем за чем он реализован — это и принцип единой ответсвенности разные вещи.
Проблема паттерна продолжается в том, что при обычных его реализациях обратится к «переиспользованию» объекта не реально. Именно потому нам на помощь приходят фасады и контейнер — фасад это структурный паттерн, он позволяет скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам. А контейнер позволяет отслеживать состояние объекта, в том числе проверять единственный экземпляр был инициализирован или нет, а темболее не мешает переиспользовать объект еще раз создавая его новые экземпляры под конкретные нужды.

Я не говорю про проблему синглтона с работой зависимостей с ним достаточно сложно работать, так же достаточно сложно следить за ним состояние объекта при необходимости работы одного объекта в нескольких потоках. К примеру JVM не позволяет проверить существует ли один экземпляр объекта в пространстве, он всего-лишь проверяет существует ли экземпляр объекта в текущем загрузчике, однако сложные проекты на java пишутся с использованием более одного загрузчика. (это для примера минуса синглтона)

В репозитории я заметил именно синглтон объекты Application, Engine, PluginManager, Router, Storage, HookManager — тестирование этих объектов очень усложнено, изолировать их методы между собой весьма сложно.

На мой взгляд на текущий момент лучше пойти с использованием паттерна DI, в том числе внедряя сервис-провайдеры, которые позволят построить как структурное приложение (Приложение —> События —> Роутер —> Модули —> Ответ), так и внедрить модульную систему, где каждый модуль сможет иметь свой сервис провайдер, а так же сможет влиять на всю систему целиком сразу после установки модуля, без необходимости писать инструкции по изменению кода (пример системы octobercms, система после установки плагина в том числе расширяет модели других объектов/системы, при этом не влияя на основную логику расширяемой модели)
Отредактирован:
0
У меня имеется проект на альто под php 7.1 и работает он весьма плачевно, пришлось достаточно сильно изменить конфигурацию


У меня под семеркой работает хорошо.
0
значит повезло :) на билде — 7.1.12 (релиз от 29.11.17) с обвязкой кеширования под memcache работает не очень. В прочем на это особо внимание не акцентируется, мне больше хочется стоящий релиз альто, чтобы не было проблем реализации которые есть сейчас :)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.