Pavel Zarubin

Или хотя бы скажите куда копать.

Начать стоит с изучения как устроена модель пользователей в smf и как она связывается со своей таблицей, после чего вместо своей таблицы подсунуть этой модели таблицу пользователей modx и если необходимо — поменять нужные атрибуты, ну и дебажить-дебажить-дебажить конечно же

Не работал с smf но не думаю что подвзять модель пользователей SMF на модель пользователей modx'a такая страшная и трудоемкая задача чтобы не выполнить это ручками

А это действительно требует отдельного поста на modxpro? Я понимаю когда выкладывают всякие хуки и инструкции для компонентов где дописать документацию невозможно или требует отдельных PR и прочих заморочек, но тут инструкция вроде как от автора компонента, я понимаю анонсы компонентов, понимаю анонсы скидок, да блин я даже понимаю посты где меняется мажорная версия какого то из компонентов, но вот это зачем?

Я лично против таких инструкций

Мне тебя значит жаль)
Ну собственно значит мне больше добавить нечего к тому что я говорил выше:

Ну а если вы боитись что пострадают продажи из за инструкции на modxpro, то наверное цена и правда завышена что сделать самому выгоднее чем покупать готовое решение. Ну лично мое имхо

В любом случае, спасибо что это не «снег на сайт»))

А еще это не уважение к другим программистам.

А это еще почему, прошу не надо обобщать и говорить за всех, я например совсем не против если мои платные дополнения кто то опишет как сделать бесплатно, да собственно я же и выкладывал инструкцию как сделать тот же сдэк и msRussianPost бесплатно, это никак не влияет на продажи, за то привлекает новичков в систему на которой вы же и работаете, которые потом у вас же будут покупать ваш же компонент, ибо в инструкции «СЛОЖНА».
Ну а если вы боитись что пострадают продажи из за инструкции на modxpro, то наверное цена и правда завышена что сделать самому выгоднее чем покупать готовое решение. Ну лично мое имхо

Это 2 соседних комментария. Наверно и тут можно выкрутиться, что там имел ввиду не это, а тут не то.

То что CMS все меньше кому то нужны никак не говорит об их колличестве, я за количеством CMS не слежу, за-то прекрасно слежу за вакансиями, и если раньше только за пределами СНГ было сложно найти работу на CMS, то сейчас и в СНГ все меньше вакансий на CMS и все больше вакансий на фреймворках от этого и от вышеперечисленных факторов такой вывод

Т.е. когда выбирают фреймворк под высокопосещаемый сайт,

Ого, кто то выбирает каждый раз разный фреймворк? Не завидую я этим людям. Обычно берут то что хорошо знают или то, у чего перспективы на долгое развитие, это, фреймворк, он создан для того, чтобы на нем делали что угодно и какой угодно производительности не вводя никаких ограничений, я сейчас говорю про PHP фреймворки, а не про гибриды по типу Spiral

MODX плохой, потому что не может держать 400 запросов в секунду

Я такого не говорил, не надо переворачивать с ног на голову, я сказал что у нас на проде опытные девопсы делают все сложнее не потому что так нужно делать всем или мой способ не безопасный, а потому что у нас система высоконагруженная и отвал ее хотя бы на 5 минут — это отвал 120 тысяч хитов, по этому собственно у нас на проде «все по другому»

Я не путаю горячее с мягким и вовсе не говорю что modx должен держать 400 запросов в секунду

Количество CMS множится

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

Ты удивишься, но тот же Laravel имеет невысокие показатели среди других фреймворков

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

Ты можешь воспринимать это как придирку, твое право.

Я просто хочу услышать хоть один способ как человек может вскрыть БД зная даже ее доступы извне не вскрыв при этом локалку) А если человек вскрывает локалку, он по любому получает все пароли от БД т.к. в php они храняться в открытом виде и никого это не парит. Ты же понимаешь что это невозможно?)

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

ведь неспроста это так, согласись

Не спроста, но у нас извини меня 40 миллионов пользователей и посещаемость 400 хостов в секунду и это только по веб части, еще есть api часть которую используют IOS/Android приложения, но какая там нагрузка знать не в моей юрисдикции.
Или ты предлагаешь рассказывать людям работающим на modx как построить контейнеры способные держать 400 хостов в секунду в течении месяцев без перебоев?

Ваня, ну придирка же)) Если кто то может выполнить php код извне у меня на сервере то ему не составит труда сделать скандир и просто отыскать файл с доступами к бд, по этому ну хватит уже, я долго думал перед тем как использовать одинаковые доступы к бд везде, нет ни одного фактора который говорил бы что это не безопасно

это ж если какие другие окружения на докер подняты, грохнет все к херам

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

Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово

Перестраховка, не более, которая позволяет грохнуть папку db в любой момент пересобрать контейнер полностью и сохранить все данные, с текущей скоростью SSD/NVME даже с тяжелыми БД операция дампа происходит довольно быстро, так почему бы не перестраховаться лишний раз?

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

Я знаю как работает мой конфиг, спасибо )))

Traefik

Не слышал, почитаю, спасибо

dnsmasq

Я его тоже использую, в том случае если нужно зарезолвить динамические поддомены, например, но полностью переходить на него не вижу смысла, hosts с 90% задач справляется на ура

https

Есть в планах прикрутить генерируемые самоподписанные сертификаты, чтобы и локальное окружение было на https

это все же небезопасно, даже если крутится в контейнерах

Почему? Бд слушает обращения только с локальной стороны, а если у кого то есть доступ к локалке, то бд уже вскрыта потому что любой php проект хранит доступы к бд прямо в коде

какой смысл постоянно наводить тоску по поводу текущего состояния и развития modx revo

Я не навожу тоску, просто объяснил человеку почему идея с форком заранее мертва, от этого мне абсолютно не тоскливо

но развитие есть

Смешно, оставлю без комментариев

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

Потому что все, в том числе и я, считают modx лучшей из CMS по сей день, и от этого в несколько раз грустнее потому что она остается актуальной даже отстав от всего мира разработки лет на 10

Вот и в этом посте уже в первых строках автор «отвешивает колкости»

Каюсь, не очень красиво получилось, наверное. Но я и в жизни не самый позитивный парень

Зачем?

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

На самом деле последней каплей для меня стал как раз последний пункт, элементарно, если организовывать нормальное логирование при разработке (а не такое как в modx) то работать на сервере становится невозможно, в нормальной разработке люди делают так:

tail -f log.log

И слушают логи только по отдельной части разрабатываемого модуля, а зачастую это несколько логов одновременно, посмотрел бы я как бы ты это делал на сервере когда таких частей надо слушать сразу 4 например.
Ну и + ко всему генерируются не обязательно логи или служебные файлы, иногда генерируются php модели, да в том же modExtra при билде xml схемы генерируются модели, которые в случае с серверной разработкой нужно выкачивать при каждом изменении

С колокльни комментатора очень легко судить, «ну сделайте мне форк, а вдруг взлетит как октябрь», а вдруг будет востребованно, а я вот например как разработчик не хочу вкладывать силы и душу в проект минимум на пол года, а скорее год. Сейчас не золотой век CMS, CMS все меньше кому то нужны уже даже в России, за пределами России я уже вообще молчу, тут бы дожить существующим CMS спокойно, а новые в принципе обречены на провал какие бы хорошие они не были. Да даже взять тот же мегапопулярный октябрь, зайди, посмотри насколько тухло у них в сообществе, посмотри на баги и детские болезни которые никто не спешит править, и это учитывая то, что октябрь на данный момент наверное для всего интернета считается самой прогрессивной CMS

Я выше описал почему нет

где от MODX осталось всё
смешно)))

Тут уже не раз обсуждался форк modx revo, но давай повторим:
Смотри, объясню тебе проблематику почему так невозможно сделать в Revo

1) Поломаешь всю совместимость с существующими компонентами, а переписывать свои компоненты никто не ринется, т.к. больше половины разработчиков уже потерялось
2) Оставлять старую админку? Но многие не довольны ExtJS, да и ExtJS 3.4 устарел, получается что нужно писать новую админку, но если писать новую админку, то даже те, кто захотят перенести свои компоненты — никогда не согласятся это сделать если еще и фронт надо будет переписывать
3) Предположим что мы решили написать новую админку на условном VUE и Rest api, идем дальше, что делаем с кодом в браузере? Такую же систему что и октября, где код можно и в файлах и браузере писать, ну ок.
4) Что делаем с системой событий? Их слишком много, они слишком нагружают систему и слишком не грамотно реализованы? Переписываем на событийную модель laravel выпилив половину не нужных событий? Ок
5) Система прав в Revo реализована плохо, не безопасно и тормознуто, тоже переписываем?

Так и что у нас от MODX то осталось в итоге? ТВ поля и пару синтаксических сахаров? Ну и получаем мы в лучшем случае Evo 2.0

А по итогу получаем мы никому не нужную CMS о которой никто не знает, без какого либо комьюнити и компонентов, которая держится на паре калек которые через год бросят эту идею в принципе

Я бы привел как хороший пример Evo 2.0, но увы нет, они как были отшельниками modx 10 лет назад, так ими и остались, комьюнити никакущее, серьезных компонентов типо minishop2 как не было, так и нет, и это при том, что у них есть офигенный бэкграунд, 10 лет назад (или 13, уже не помню) они решили делать революцию и идти в ногу со временем выпуская сначала свои доработанные сборки modx evo, а потом и совсем отделившись, друг, напомню, они шли к тому что есть у них сейчас больше 10 лет и все равно остались на задворках сайтостроительства имее рок-н-рольский бэкграунд и откусив не малую часть тогдашнего сообщества. Как бы не было грустно, но дайте modx спокойно уже умереть

Просто ознакомьтесь с Evo 2.0

Я знаком, так же как и с автором

Только вот Evo 2.0 это не MODX, а скорее Lumen с синтаксическим сахаром под MODX, прочитайте внимательно мой комментарий, цитирую

Без изменений ядра

А в Evo осталась только идеология от modx, которая будем честны также уже давно устарела

И собственно именно по этому Evolution избавился от приставки «Modx» и давненько уже себя позиционирует как совершенно другая CMS

Добрый, она означает что при инициализации дает выбрать что разворачивать modx или laravel и на основе этого подставляет нужные БД и генерирует конфиги, посмотрите видео, там в целом все понятно.

Уже давно мечтаю о связке MODX с Laravel

Когда начинал знакомится с laravel пробовал это сделать, работает, но получается монстр франкенштейна)) Без изменений ядра совершенно безсмысленное и трудоемкое занятие, в итоге ушел в полностью в laravel и yii, с modx'ом меня связывает пара клиентов, мои компоненты и офигенное сообщество)

А как себя ведёт БД в докере на production

К слову и без всяких виртуализаций на статичном mysql у меня бывало что сыпалась какая то из табличек и из за этого ложился вообще весь mysql наглухо, особенно это часто наблюдается на modx с включенными БД сессиями (по умолчанию) и бешаной посещаемостью

Пока только видел, что так совсем не стоит делать по ряду причин.

Вообще чтобы в продакшене железобетонно держать контейнеры есть такая штука как kubernetes, на ней многие хостеры строят например хостинги) И не факт что ваш хостер не хранит ваши файлы в контейнерах)
Раньше — да, распространенное мнение было, но не сейчас, например у нас в компании наш продакшн лежит в контейнерах под управлением kubernetes, правда и наш продакшн настраивал не Павел Зарубин, а опытные девопсы, по этому конкретно за свою сборку могу говорить только за себя, что пока что инцидентов по ней не было, но это вовсе не значит что не стоит использовать докер на продакшене