Сначала отвечу про php7 — у меня сейчас несколько проектов работает на текущей версии Альто в конфигурации nginx+php7. Для новой версии минимум php 5.6 значится не потому, что под семеркой не будет работать, а просто потому, что фичи семерки в ней не используются. Но сам код отлично крутится под php7.
Насчет синглтонов вопрос интересный, но несколько размытый, т.к. не очень понятно, о каких именно компонентах идет речь. Роутер в движке по любому один. Конфигуратор — тоже. Так почему они не могут быть синглтонами? Кстати в том же Ларавеле механизм фасадов реализует доступ к конкретным одиночным экземпларам классов в сервис-контейнере. Формально это, разумеется, не синглтон, но фактически реализует ту же идею — есть классы, у которых в приложении создается только по одному экземпляру объектов.
Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).
C Simfony 4 не работал, не знаю, что там и как, но несколько проектов на Slim сделал. И в одном из проектов, стати, на Slim посадил ларавеловский Eloquent ORM. Так что если вдруг сложилось впечатление, что я не знаю современных движков — это не так. ))) Знаю, пробую на практике, смотрю, что хорошего можно из них взять в Альто.
Нормальный роутинг обязательно будет (правда, вопрос остается — старый лайвстритовский роутинг оставлять? или ну его?). А про остальное надо говорить более конкретно — мол, вот такой-то компонент я предлагаю реализовать так-то. Будем обсуждать.
Могу только добавить, что мне нравится в Альто разделение классической модели на составные части — есть сущность, которая хранит свойства модели, и есть модуль, которые содержит в себе методы обработки модели. В работе с Eloquent ORM прям очень напрягает то, что там все это в одной куче. Но это может быть мое чисто субъективное отношение
Если в качестве веб-сервера используется Apache, то нужно проверить, есть в корне файл .htaccess
Если Nginx — нужно настроить в конфиге сервера в качестве точки единого входа файл index.php
Но вот этот «релиз» очень печалит. Тут некоторые подгоняли админа, мол выкладывай что есть, а он возьми и выложи нерабочую цмс с кучей косяков и сомнительными улучшениями
Возможно, я не вполне четко описал в топике, что это лишь рабочий репозитарий. Сейчас добавил, выделив жирным — так понятнее?
Да ладно, без обид )))
Но мне, кстати, очень интересно (и даже полезно) было бы узнать о чувствах и планах относительно Альто всех, кому этот проект не безразличен
Кстати, о Ларавел — вот что мне у них нравится, так это их Eloquent ORM. Какое-то время ходил кругами вокруг него, но так и не придумал, как это в Альто ввинтить, не круша всей архитектуры. А было б весьма неплохо, ИМХО.
Что касается перевода прям всего движка — вот как-то не вижу в этом реальной необходимости (кроме чисто маркетингового хайпа). Но готов обсудить, если будут какие-то серьезные аргументы, а не просто «это круто и клево».
Так в том-то и цимус, что у меня тоже интерес сугубо шкурный — мне нужен пусть далекий от идеала, но реально работающий движок. Но у меня слишком много уже накопилось всяческих наработок в виде плагинов, аддонов и просто хардкодных костылей, которые я сейчас хочу перенести уже в движок, а то сам иногда путаюсь, где что как реализовано
Во-первых, говнокодить и криво строить архитектуру движка успешно можно на любом фреймворке и на любой платформе. Поэтому сам по себе переход на какой-то фреймворк — не панацея. Да, это может вызвать некоторый интерес со стороны сообщества фреймворка, но не более. Чтобы кто-то начал писал расширения, нужно сначала выкатить готовый результат, который удовлетворит это сообщество. Никто не ломанется писать ядро движка, люди будут ждать, чего из этого выйдет. Есть тут желающие переписывать с нуля Альто на какой-то иной фреймворк? Нет? Ну, значит, проехали.
А чтобы были разработчики — нужно чтобы писать под нее было удобно/выгодно/перспективно.
С этим хрен поспоришь. Но если танцевать «от печки» (то бишь, от «удобно»), то, значит, нужно разбирать вполне конкретные недостатки архитектуры Альто, и предлагать решения, как их исправить. И возможно (подчеркиваю — ВОЗМОЖНО, но не наверняка) может оказаться, что большинство решений базируется на использовании тех или иных классов/библиотек из какого-то популярного фреймворка. И тогда уже вполне естественным образом встает вопрос о переезде на этот фреймворк целиком. Вот такой подход мне кажется вполне логичным. А все остальное — это как-то за уши притянутое и надежда на маленькое волшебство.
Я, кстати, не раз пытался заводить дискуссии относительно тех или иных решений, но как-то не очень они получались. В основном, все сводилось к тому, что «та сделай, а мы посмотрим, что у тебя получится». Не, я не обижаюсь нисколько, просто констатирую.
В общем, резюмирую — я считаю, что портировать CMS на сторонний фреймворк имеет смысл только при следующих условиях:
1) Будет совершенно четко понятно, какие именно болячки Альто и каким способом будут вылечены.
2) Будет кто-то еще, кроме вашего покорного слуги, кто готов будет пилить код, а не ждать готового результата
Пока же я продолжаю улучшать движок теми путями, что описал в топике
По поводу Вордпресса — это не совсем так, конечно. Одно время прилично так довелось с сайтами на нем ковыряться, так поверьте — до фига там было проблем совместимости и плагинов с версиями движка, и плагинов друг с другом, и с шаблонами. Другое дело, что там этих плагинов и шаблонов немерянно, и если с каким-то возникают проблемы, то, как правило, можно альтернативу найти. Но в целом не так радужно там, проблем хватает
Да, что-то такое было, Макс начинал с каким-то напарником, а потом отпочковался в ЛС. Это особо не афишировалось, как в истории с Альто, но было. Но исходный движок был что-то еще более стихийным и бессистемным, чем ЛС.
Но вот смотрите, парни — вас двое, но уже один топит за Лару, другой за Симфони. Это наглядный пример, того, что какой бы вариант не был выбран, все равно он кого-то разочарует и у этого варианта будут противники. Переписывать ядро вообще с нуля — такого ни в мыслях, ни в планах нет. Чисто в теории, в принципе, вариант переписывания с нуля я готов рассматривать, но при двух условиях:
1) Нужно какое-то более аргументированное обоснование. Не потому что «это круто и популярно», а как-то более сухо и безэмоционально — «раз..., два..., три...»
2) Человек не просто аргументирует, но и берет на себя определенный объем работ, вот буквально: «зуб даю, что сделаю то-то и то-то при миграции на такой фреймворк».
Не обещаю, что обязательно соглашусь ядро Альто переводить на сторонний фреймворк, но без этих двух критериев даже рассматривать такой вариант не стану. Я уже не раз говорил, что Альто мне нужен самому, и пусть он будет не идеальный, но рабочий, чем классно спроектированный, но дохлый.
Тут аккурат подошел бы статус из ВК «Всё сложно» ))) Вопросы понимаю, но не знаю, как ответить на них максимально конкретно.
1. «Возможно ли...?» — надо смотреть, что за допилы и как они вписываются в движок
2. «Насколько лучше/круче/оптимизированнее...?» — да, лучше, но в чем мерить?
3. «Что будет под капотом?» — для начала все то же, но с обновленными сторонними библиотеками, со значительно уменьшенной массой легаси кода
4. А вот на реально или нет вообще не знаю как ответить. Разумеется, буду только приветствовать, если кто-то впишется в разработку. Но вот вписываются ли ближайшие изменения в чужое понимание «хорошо/плохо» — этого я не знаю.
Вообще, кардинальный способ реально одним махом сделать все правильно — это начать с чистого листа. При этом взять за основу какую-то готовую кодовую базу (Лару, Симфони, Уии2, может, даже ПхПикси, либо что-то более низкоуровневое — например, классы от Ауры, или вообще Слим какой-нибудь, в общем, выбор широк) — и уже на этом наворачивать, чего хочется. И можно даже плюсы дополнительные получить, вызвав интерес у уже сложившегося сообщества выбранного фреймворка (о! цмс на нашем любимом фреймворке!). Но я не готов к такому кардинальному шагу. Мне такое предлагали уже несколько раз, но каждый раз подразумевалось, что мне расскажут, как надо правильно делать, а реализовывать я это буду сам. Но у меня не так много свободного времени, чтоб я мог один это все потянуть, и не так много свободных денег, чтоб под это дело кого-то нанять.
Поэтому мой план иной — сначала выбросить то, что уже точно не нужно (ту же пресловутую ЛС-совместимость). Потом, сохраняя концепцию построения движка, заменять отдельные компоненты более современными разработками. Например, сохраняя нынешнюю гибкость роутинга и настройку его через конфиги, собственно сам роутинг построить на Aura.Router.
В общем, давайте так: я выкачу на днях драфт новой версии, а там будет видно — либо «фу, все плохо, я ухожу», либо «а ничо так, из этого может что-то получиться, предлагаю то-то и то-то»
Про Gearman знаю, про RabbitMQ, был у нас даже проект, где Кролика активно использовали, но там действительно нужно было работать с очередями, т.к. источников запросов было на порядки больше, чем обработчиков.
В моем же случае были следующие соображения:
1) Мне не хотелось выстраивать запросы в очередь (возможно, в будущем придется это сделать, но не сейчас), мне нужно было по запросу сразу же запускать на сервере процесс. А потом раз в N секунд проверять — завершился он или нет. И если вдруг потребуется — убить процесс. Если клиентов несколько, то каждый может запустить свой процесс сразу по запросу независимо от других.
2) По возможности обойтись стандартными средствами PHP без установки дополнительного софта на сервер.
1) Picture.plus — действительно живет на яндексовских ДНС. Но сменить их одним махом я не рискую, т.к. там же живет почта, нужным образом настроенная, интегрированная с сервисом рассылки, с хорошей доставляемостью. Поэтому пока думаю, как аккуратно переехать на другие ДНС, ничего не сломав при этом.
2) altocms.ru — этот сайт только что переехал на новый сервер и на новые ДНС. Они НЕ яндексовские и никак не могут быть под санкциями, но, видимо, из-за их смены и из-за днс-кеша провайдеров сайт какое-то время был недоступен. Собственно, хотелось бы знать, нормальный ли сейчас доступ к этому сайту у юзеров с украинскими провайдерами
В черновом варианте планирую в паблик выложить в конце этой недели. Но сколько времени уйдет на доводку, багфиксы и проч., трудно спрогнозировать
Не проще ли развивать то, что уже есть?
Приведу пример, правда, понятен он будет лишь тем, кто немного в коде разбирается. Как сейчас происходит добавление в базу или обновление записи какой-то сущности? А так: пишется SQL-запрос, где явно перечисляются все добавляемые или обновляемые поля. Если в каком-то плагине возникает необходимость свое поле к сущности добавить, то для того, чтоб в процессе работы сущности нормально добавлялись/обнавлялись — вот тут начинаются танцы с бубнами и костылями, кто-то через хуки это делает, кто-то методы и SQL-запросы переписывает, иные еще как-то изгаляются. А потом начинаются несовместимости плагинов, плагинов с движком новой версии, проблемы обновления и все такое. Не поленился, посмотрел, как в ЛС 2.х сейчас это решается — а все так же, как был этот гемор, так и остался.
Нормально это? Нет! Можно убить этот гемор и всем разработчиками хорошо сделать? Элементарно! Но! Вот только одно это улучшение сразу ломает совместимость со многими плагинами и старыми версиями напрочь. И все равно встает этот выбор — либо продолжать плясать по старым граблям, либо избавиться от них, но и от старых плагинов тоже.
И таких вот узких мест в движке — полно! Я уж не говорю о том, что 100%-ной совместимости со старыми ЛС-плагинами все равно уже не получается добиться — что-то работает, а что-то нет. А поддерживать эту самую совместимость становится все сложнее и сложнее. И в какой-то момент, рано или поздно все равно придется бросить этот «чемодан без ручки», набитый милым и привычным, но устаревшим барахлом. Так, может, лучше сделать это сейчас?
Я понимаю, что люди не будут годами ждать обновлений. Ну, ок, если они найдут что-то лучше — значит, так тому и быть. Значит буду продолжать пилить Альто для себя. И для того числа людей, кому движок интересен, сколько бы их ни было.
Не, у меня не сервер очередей. Мне нужно из движка запустить внешнюю программу (процесс) и, получив PID, периодически проверять, не завершился ли процесс, а так же иметь возможность его убить, при необходимости. Причем, нужно мне это делать и под Виндой, и под Линуксом. Видел похожие компоненты у Симфони, еще у кого-то, но в силу разных причин сторонние готовые библиотеки не подошли
Для работы под HTTPS нужно выполнить правильные настройки в app/config/config.local.php. А именно:
1) Явно указываем протокол HTTPS в URL сайта:
2) Для ассетов задаем относительный URL:
И все!
Конечно, если сайт на альто не в корне домена, а в папке, то и указывать нужно с учетом этой папки, например, если сайт установлен в папку /alto, то:
Насчет синглтонов вопрос интересный, но несколько размытый, т.к. не очень понятно, о каких именно компонентах идет речь. Роутер в движке по любому один. Конфигуратор — тоже. Так почему они не могут быть синглтонами? Кстати в том же Ларавеле механизм фасадов реализует доступ к конкретным одиночным экземпларам классов в сервис-контейнере. Формально это, разумеется, не синглтон, но фактически реализует ту же идею — есть классы, у которых в приложении создается только по одному экземпляру объектов.
Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).
C Simfony 4 не работал, не знаю, что там и как, но несколько проектов на Slim сделал. И в одном из проектов, стати, на Slim посадил ларавеловский Eloquent ORM. Так что если вдруг сложилось впечатление, что я не знаю современных движков — это не так. ))) Знаю, пробую на практике, смотрю, что хорошего можно из них взять в Альто.
Нормальный роутинг обязательно будет (правда, вопрос остается — старый лайвстритовский роутинг оставлять? или ну его?). А про остальное надо говорить более конкретно — мол, вот такой-то компонент я предлагаю реализовать так-то. Будем обсуждать.
Могу только добавить, что мне нравится в Альто разделение классической модели на составные части — есть сущность, которая хранит свойства модели, и есть модуль, которые содержит в себе методы обработки модели. В работе с Eloquent ORM прям очень напрягает то, что там все это в одной куче. Но это может быть мое чисто субъективное отношение
Если Nginx — нужно настроить в конфиге сервера в качестве точки единого входа файл index.php
Но мне, кстати, очень интересно (и даже полезно) было бы узнать о чувствах и планах относительно Альто всех, кому этот проект не безразличен
Что касается перевода прям всего движка — вот как-то не вижу в этом реальной необходимости (кроме чисто маркетингового хайпа). Но готов обсудить, если будут какие-то серьезные аргументы, а не просто «это круто и клево».
Во-первых, говнокодить и криво строить архитектуру движка успешно можно на любом фреймворке и на любой платформе. Поэтому сам по себе переход на какой-то фреймворк — не панацея. Да, это может вызвать некоторый интерес со стороны сообщества фреймворка, но не более. Чтобы кто-то начал писал расширения, нужно сначала выкатить готовый результат, который удовлетворит это сообщество. Никто не ломанется писать ядро движка, люди будут ждать, чего из этого выйдет. Есть тут желающие переписывать с нуля Альто на какой-то иной фреймворк? Нет? Ну, значит, проехали.
С этим хрен поспоришь. Но если танцевать «от печки» (то бишь, от «удобно»), то, значит, нужно разбирать вполне конкретные недостатки архитектуры Альто, и предлагать решения, как их исправить. И возможно (подчеркиваю — ВОЗМОЖНО, но не наверняка) может оказаться, что большинство решений базируется на использовании тех или иных классов/библиотек из какого-то популярного фреймворка. И тогда уже вполне естественным образом встает вопрос о переезде на этот фреймворк целиком. Вот такой подход мне кажется вполне логичным. А все остальное — это как-то за уши притянутое и надежда на маленькое волшебство.
Я, кстати, не раз пытался заводить дискуссии относительно тех или иных решений, но как-то не очень они получались. В основном, все сводилось к тому, что «та сделай, а мы посмотрим, что у тебя получится». Не, я не обижаюсь нисколько, просто констатирую.
В общем, резюмирую — я считаю, что портировать CMS на сторонний фреймворк имеет смысл только при следующих условиях:
1) Будет совершенно четко понятно, какие именно болячки Альто и каким способом будут вылечены.
2) Будет кто-то еще, кроме вашего покорного слуги, кто готов будет пилить код, а не ждать готового результата
Пока же я продолжаю улучшать движок теми путями, что описал в топике
Но вот смотрите, парни — вас двое, но уже один топит за Лару, другой за Симфони. Это наглядный пример, того, что какой бы вариант не был выбран, все равно он кого-то разочарует и у этого варианта будут противники. Переписывать ядро вообще с нуля — такого ни в мыслях, ни в планах нет. Чисто в теории, в принципе, вариант переписывания с нуля я готов рассматривать, но при двух условиях:
1) Нужно какое-то более аргументированное обоснование. Не потому что «это круто и популярно», а как-то более сухо и безэмоционально — «раз..., два..., три...»
2) Человек не просто аргументирует, но и берет на себя определенный объем работ, вот буквально: «зуб даю, что сделаю то-то и то-то при миграции на такой фреймворк».
Не обещаю, что обязательно соглашусь ядро Альто переводить на сторонний фреймворк, но без этих двух критериев даже рассматривать такой вариант не стану. Я уже не раз говорил, что Альто мне нужен самому, и пусть он будет не идеальный, но рабочий, чем классно спроектированный, но дохлый.
1. «Возможно ли...?» — надо смотреть, что за допилы и как они вписываются в движок
2. «Насколько лучше/круче/оптимизированнее...?» — да, лучше, но в чем мерить?
3. «Что будет под капотом?» — для начала все то же, но с обновленными сторонними библиотеками, со значительно уменьшенной массой легаси кода
4. А вот на реально или нет вообще не знаю как ответить. Разумеется, буду только приветствовать, если кто-то впишется в разработку. Но вот вписываются ли ближайшие изменения в чужое понимание «хорошо/плохо» — этого я не знаю.
Вообще, кардинальный способ реально одним махом сделать все правильно — это начать с чистого листа. При этом взять за основу какую-то готовую кодовую базу (Лару, Симфони, Уии2, может, даже ПхПикси, либо что-то более низкоуровневое — например, классы от Ауры, или вообще Слим какой-нибудь, в общем, выбор широк) — и уже на этом наворачивать, чего хочется. И можно даже плюсы дополнительные получить, вызвав интерес у уже сложившегося сообщества выбранного фреймворка (о! цмс на нашем любимом фреймворке!). Но я не готов к такому кардинальному шагу. Мне такое предлагали уже несколько раз, но каждый раз подразумевалось, что мне расскажут, как надо правильно делать, а реализовывать я это буду сам. Но у меня не так много свободного времени, чтоб я мог один это все потянуть, и не так много свободных денег, чтоб под это дело кого-то нанять.
Поэтому мой план иной — сначала выбросить то, что уже точно не нужно (ту же пресловутую ЛС-совместимость). Потом, сохраняя концепцию построения движка, заменять отдельные компоненты более современными разработками. Например, сохраняя нынешнюю гибкость роутинга и настройку его через конфиги, собственно сам роутинг построить на Aura.Router.
В общем, давайте так: я выкачу на днях драфт новой версии, а там будет видно — либо «фу, все плохо, я ухожу», либо «а ничо так, из этого может что-то получиться, предлагаю то-то и то-то»
В моем же случае были следующие соображения:
1) Мне не хотелось выстраивать запросы в очередь (возможно, в будущем придется это сделать, но не сейчас), мне нужно было по запросу сразу же запускать на сервере процесс. А потом раз в N секунд проверять — завершился он или нет. И если вдруг потребуется — убить процесс. Если клиентов несколько, то каждый может запустить свой процесс сразу по запросу независимо от других.
2) По возможности обойтись стандартными средствами PHP без установки дополнительного софта на сервер.
Вот, исходя из этих условий и решалась задача
nslookup -type=ns altocms.ru
что выдаст?
1) Picture.plus — действительно живет на яндексовских ДНС. Но сменить их одним махом я не рискую, т.к. там же живет почта, нужным образом настроенная, интегрированная с сервисом рассылки, с хорошей доставляемостью. Поэтому пока думаю, как аккуратно переехать на другие ДНС, ничего не сломав при этом.
2) altocms.ru — этот сайт только что переехал на новый сервер и на новые ДНС. Они НЕ яндексовские и никак не могут быть под санкциями, но, видимо, из-за их смены и из-за днс-кеша провайдеров сайт какое-то время был недоступен. Собственно, хотелось бы знать, нормальный ли сейчас доступ к этому сайту у юзеров с украинскими провайдерами
Приведу пример, правда, понятен он будет лишь тем, кто немного в коде разбирается. Как сейчас происходит добавление в базу или обновление записи какой-то сущности? А так: пишется SQL-запрос, где явно перечисляются все добавляемые или обновляемые поля. Если в каком-то плагине возникает необходимость свое поле к сущности добавить, то для того, чтоб в процессе работы сущности нормально добавлялись/обнавлялись — вот тут начинаются танцы с бубнами и костылями, кто-то через хуки это делает, кто-то методы и SQL-запросы переписывает, иные еще как-то изгаляются. А потом начинаются несовместимости плагинов, плагинов с движком новой версии, проблемы обновления и все такое. Не поленился, посмотрел, как в ЛС 2.х сейчас это решается — а все так же, как был этот гемор, так и остался.
Нормально это? Нет! Можно убить этот гемор и всем разработчиками хорошо сделать? Элементарно! Но! Вот только одно это улучшение сразу ломает совместимость со многими плагинами и старыми версиями напрочь. И все равно встает этот выбор — либо продолжать плясать по старым граблям, либо избавиться от них, но и от старых плагинов тоже.
И таких вот узких мест в движке — полно! Я уж не говорю о том, что 100%-ной совместимости со старыми ЛС-плагинами все равно уже не получается добиться — что-то работает, а что-то нет. А поддерживать эту самую совместимость становится все сложнее и сложнее. И в какой-то момент, рано или поздно все равно придется бросить этот «чемодан без ручки», набитый милым и привычным, но устаревшим барахлом. Так, может, лучше сделать это сейчас?
Я понимаю, что люди не будут годами ждать обновлений. Ну, ок, если они найдут что-то лучше — значит, так тому и быть. Значит буду продолжать пилить Альто для себя. И для того числа людей, кому движок интересен, сколько бы их ни было.