easyComm 3, работа в MODX 3


Приветствую участников сообщества!

В этой заметке я лишь хотел сказать о том, что в магазин Modstore выложена версия easyComm 3.0.1-pl, которая работает в MODX 3!


Сейчас вы можете скачать 2 версии компонента в зависимости от вашей версии MODX (1.10.3-pl или 3.0.1-pl), выбор происходит автоматически.

Нового функционала нет, я лишь адаптировал компонент для MODX 3. Даже наоборот, я пока отключил поддержку плагинов, т.е. вы НЕ СМОЖЕТЕ добавить поля как это описано в текущей документации. Думаю, к этому можно будет вернуться позже.

В общем, если вы вдруг рискнете сделать продакшн сайт на альфа версии MODX 3, знайте, easyComm вам в помощь!)))
Кстати, чисто потыкать и посмотреть на работу я думаю можно на modhost, создав тестовый сайт.

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

Несколько ссылок по теме, чем я пользовался:
1. Статья «Подготовка дополнения для работы в MODX 3»: modx.pro/development/19429
2. Исходники Collection, адаптированные под modx 3: github.com/modxcms/Collections/tree/for-3
3. Исходники pdoTools, адаптированные под modx 3: github.com/bezumkin/pdoTools/tree/3.x
и статьи из официальной документации
4. Dependency Injection Container docs.modx.com/3.x/en/extending-modx/di-container
5. Namespaces docs.modx.com/3.x/en/extending-modx/namespaces

Основные шаги, как запустить компонент на MODX 3

1. Переносим код компонента в папку src (см. исходники Collections, pdoTools). Теперь мы вовсю пользуемся namespace и use.
В /src у нас будут: папка Model с объектами, процессоры, основной код компонента.

2. Файл схемы easycomm.mysql.schema.xml меняется.
Вот пример того, как теперь выглядит схема в easyComm (кусочек для демонстрации):
<?xml version="1.0" encoding="UTF-8"?>
<model package="EasyComm\Model\" baseClass="xPDO\Om\xPDOObject" platform="mysql" defaultEngine="MyISAM" version="3.0">
    <object class="ecThread" table="ec_threads" extends="xPDO\Om\xPDOSimpleObject">
    .....
    </object>
</model>
Местоположение этого файла не меняется, но вот на его основе уже генерируется уже немного другая модель (у меня это происходит в файле /_build/build.model.php).
Код для генерации модели:
$sources = array(
    'root' => $root,
    'build' => $root . '_build',
    'source_core' => $root . 'core/components/' . PKG_NAME_LOWER,
    'src' => $root . 'core/components/' . PKG_NAME_LOWER . '/src',
    'model' => $root . 'core/components/' . PKG_NAME_LOWER . '/src/Model',
    'schema' => $root . 'core/components/' . PKG_NAME_LOWER . '/schema',
    'xml' => $root . 'core/components/' . PKG_NAME_LOWER . '/schema/' . PKG_NAME_LOWER . '.mysql.schema.xml',
);
................

/** @var xPDOManager $manager */
$manager = $modx->getManager();
/** @var xPDOGenerator $generator */
$generator = $manager->getGenerator();

// Remove old model
rrmdir($sources['model'] . '/mysql');

// Generate a new one
$generator->parseSchema($sources['xml'], $sources['src'], array('namespacePrefix' => PKG_NAME, 'update' => 0));

3. В методах getObject, newObject, newQuery и других с параметром $class нам нужно указывать полностью класс объекта:
// Пример 1
$message = $modx->getObject(EasyComm\Model\ecMessages::class, 1);
// Пример 2
$chunk = $modx->newObject(modChunk::class);
Это же касается случаев, когда мы делаем JOIN, к примеру.

4. Теперь мы не пользуемся
$modx->getService('easyComm');
, вместо этого у нас эти методы:
$modx->services->add('EasyComm', new EasyComm($modx));
$modx->services->has('EasyComm');
$modx->services->get('EasyComm');
Здесь примеры правильного использования.

5. Загрузка модели теперь может быть автоматической, для чего достаточно в папке \core\components\easycomm\ поместить файл bootstrap.php следующего содержания:
<?php
/**
 * @var \MODX\Revolution\modX $modx
 * @var array $namespace
 */

$modx->addPackage('EasyComm\Model', $namespace['path'] . 'src/', null, 'EasyComm\\');
$modx->services->add('EasyComm', function($c) use ($modx) {
    return new EasyComm\EasyComm($modx);
});

6. Процессоры запускаем чуть по другому, нужно указывать класс процессора.
Было:
$modx->runProcessor('object/create', $data, array('processors_path' => $config['processorsPath']));
Стало:
$corePath = $modx->getOption('ec_core_path', $config, $modx->getOption('core_path') . 'components/easycomm/');
$processorsPath = $corePath . 'src/Processors/';
$modx->runProcessor(EasyComm\Processors\Message\Create::class, $data, array('processors_path' => $processorsPath));
Или вот пример для очистки кеша:
$modx->runProcessor('System/ClearCache');

Все эти изменения приводят к тому, что на переписывание компонента ушло около 4-х дней (пусть и не полных).
Обратной совместимостью здесь и не пахнет =)
Если будут вопросы в процессе адаптации ваших дополнений — пишите в комментариях!
Наумов Алексей
23 мая 2020, 11:44
modx.pro
381
+14
Поблагодарить автора Отправить деньги

Комментарии: 26

Василий Наумкин
24 мая 2020, 05:00
+1
Это, наверное, первое платное дополнение в истории для MODX 3.

Обратной совместимостью здесь и не пахнет =)
Да и не должно было, по идее. Но вот эти все метания с «а давайте сохраним совместимость» привели к трате лишних пары лет, выгоранию основных разработчиков и нынешней стагнации 3й версии.

Расскажи потом, сколько будет закачек. У pdoTools вот так:
    Сергей Шлоков
    24 мая 2020, 07:13
    +5
    Если честно, я считаю тратой времени делать дополнения для MODX3. У меня вообще вот эта движуха с переписыванием дополнений для альфы MODX3 (даже не беты) вызвало ощущение какого-то сюра. Это как делать какие-то прибамбасы для ё-мобиля.
    Я вообще скептически отношусь к MODX3. Но повышенная активность в нашем сообществе в прошлом году подтолкнула на попытку перехватить инициативу у хозяев MODX и пойти по упрощенному пути развития. Идею радостно поддержали, но уже через месяц я понял, что я один в поле воин. Ручеёк энтузиазма быстро пересох. И тогда я задавал себе вопросы — нахер ты туда влез, тебе оно нужно, заняться больше не чем?

    В апреле вот как-то опять в телеге поднялась тема «Ну сколько можно ждать MODX3». Опять наполнились решимостью сделать хотя бы админку. Я подумал, а чем чёрт не шутит. Может всё-таки взлетит? Согласился. Пригласили фронтэндщиков, дизайнеров. Леонид по доброте душевной даже ресурс выделил. Я за пару дней развернул тикеты, чтобы было где собираться. Но что вы думаете? Энтузиазма у всех хватило только на ссылки на варианты админок. Всё!!! Все эти верстальщики, дизайнеры даже картинку не смогли нарисовать, не говоря уже о каком-то HTML макете. Практически сразу после решения начать пилить админку основная масса энтузиастов бросилась на минишоп2. Причем для второй версии MODX. Месяц уже в телеге только эта тема бурлит.

    Лично у меня больше никаких иллюзий ни про MODX3, ни про альтернативные решения его развития не возникает. Пара ребят смогла Evolution 2 родить. Сообщество Revolution гораздо больше, но тут таких не нашлось. Очень жаль.
      Василий Наумкин
      24 мая 2020, 07:54
      0
      Если честно, я считаю тратой времени делать дополнения для MODX3. У меня вообще вот эта движуха с переписыванием дополнений для альфы MODX3 (даже не беты) вызвало ощущение какого-то сюра. Это как делать какие-то прибамбасы для ё-мобиля.
      Без обновления дополнений никто не перейдёт на новую версию системы. Без перехода на новую систему, её не допилят до стабильного состояния.

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

      @Наумов Алексей скажи, если надо флуд потереть — а то мы тебе сейчас тут всё нытьём про MODX 3 зальём
        Сергей Шлоков
        24 мая 2020, 08:37
        0
        Не со всем соглашусь. Много примеров когда энтузиасты всё решали. Из ближайшего — Evolution 2.0. Вспомним YII2. И много ещё чего можно вспомнить.
        И пилить дополнения для альфы ещё то занятие. Помню про Ангуляр, где API для альфы и стабильной версии сильно отличались. На то она и альфа. Это просто макет. Попробовать, пощупать, потестить и решить — идем дальше прямо или перпендикулярно.

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

        Согласен, что без дополнений любая CSM нафиг не нужна. Я уже говорил, что готов переделать (если честно, вообще переписать всё заново) свои, но с понимаем, что это будет нужно. А пока я в очередной раз могу сказать (уже даже более уверенно, чем в прошлом году), что MODX3 никогда не выйдет.

        Но этого мы тоже не наблюдаем, значит оно никому не нужно.
        Согласен на все свои 100.

        П.С. Да простит нас Алексей за сей оффтоп. В принципе, мы говорим в контексте этой статьи. Но на всё его воля ))

        П.П.С. А для обсуждения быть или не быть MODX3 есть отдельные темы.
          Василий Наумкин
          24 мая 2020, 09:02
          +1
          Из ближайшего — Evolution 2.0
          Кстати, где он? Там никто кроме Димы его особо не использует, а Дима использует его для нужд своей веб-студии.

          То есть, Open Source проект в итоге стал проектом одной студии. Что как раз подтверждает мою мысль, что должна какая-то сила тащить проект и вкладываться в него финансово. У MODX есть LLC, но им это явно не интересно.

          Посмотри на активность modx.im — а ведь это, в отличие от Revolution, наверное единственный сайт по этой системе. Там тишина и запустение, даже мёртвый LiveStreet не заменили до сих пор, и https не работает.

          Про YII2 я ничего сказать не могу, может там сообщество само организовалось и затащило разработку мажорной версии, конечно. Но верится в это с трудом, если есть ссылка почитать — кидай.
            Юрий
            24 мая 2020, 11:30
            +1
            Вот ещё одна мысль, почему так происходит с MODX. Это его позиционирование на рынкке движков и фреймвёрков. Есть предположение, что он совершенно недооценён пользователями даже в своей нише, а это в свою очередь приводит к метаниям разработчиков и к неуверенности в завтрашнем заработке. Получается замкнутый круг. Не хотелось бы именно в этом топике развивать эту тему. Может имеет смысл в отдельной теме, но только не с заголовком «Будущее MODX 3», а, например, «Как разработчикам MODX помочь друг другу зарабатывать с помощью MODX?». Что-то в этом духе. Возможно с помощью специализированного сервиса фриланса или сервиса готовых решений, только не для разработчиков, а для конечных пользователей. Иначе говоря как-то застимулировать разработчиков перспективой заработков на MODX. Тогда и дело может пойти.
        Баха Волков
        24 мая 2020, 08:39
        0
        Практически сразу после решения начать пилить админку основная масса энтузиастов бросилась на минишоп2. Причем для второй версии MODX. Месяц уже в телеге только эта тема бурлит.
        @Сергей Шлоков Я тебя иногда не понимаю. Не знаю на счет основной «массы», но я контрибьютор ms2 с сентября прошлого года.

        P.S. Причем я еще до начала движухи выражал скептичность (вспомни общение в Зуме) и говорил, цитата: «Нужно просто оставить MODX в покое умирать, хоть и она очень долго будет умирать, но все же».

        И еще кидать камни на фротэндеров тоже странно, без дизайна они должны накидать видимо «что-то с чем-то»
        Наумов Алексей
        Вчера в 09:29
        +2
        Да, чуть нафлудили, снова на тему «не дождемся», ну да ладно, @Василий Наумкин пусть остается, не надо чистить)

        Насчет замкнутый круг согласен… пока нет дополнений, никто не возьмет MODX 3 как основу для сайта, а пока нет сайтов — и нет спроса на дополения.

        Я проделал эту работу с двумя целями: 1) хоть чуть-чуть разорвать этот круг 2) познакомится с MODX 3, т.к. я до этого даже и демку не смотрел, только мельком статьи просматривал. А сейчас хоть увидел отличия (и не только снаружи, но и внутри).

        Что касается @Сергей Шлоков
        И пилить дополнения для альфы ещё то занятие. Помню про Ангуляр, где API для альфы и стабильной версии сильно отличались. На то она и альфа. Это просто макет. Попробовать, пощупать, потестить и решить — идем дальше прямо или перпендикулярно.
        то поправимо все я думаю, если конечно кардинально не поменяют что-нибудь, например ExtJS уберут)))))
          Артур
          Вчера в 20:32
          0
          Комрады, раз уж флудим, может тезисно объясните, а что не так с нынешней версией modx? Я всего год как пришёл в разработку вообще и на Modx в частности, но пока лично для меня самое большое неудобство это ExtJs, потому как я не знаю что это за зверь, а в остальном я нарадоваться не могу, поскольку и представить не мог, что всего через год буду писать свою CRM. Конечно она достаточно простая, поскольку не универсальная, но всё же. И это благодаря modx и @Василий Наумкин. Мне не понятно как можно сделать modx ещё лучше?)))
            Павел Бигель
            Вчера в 21:00
            0
            MODX от современных трендов разработки отстал лет этак на 15
            При этом в нем огроменная куча нюансов которые нужно учитывать.

            Так или иначе — MODX удобный инструмент который решает огромное кол-во задач мелкого-среднего калибра и в текущем виде.
              Alexander V
              5 часов назад
              0
              MODX от современных трендов разработки отстал лет этак на 15
              На 30
                Василий Наумкин
                3 часа назад
                0
                Совсем с ума-то не сходите, composer появился в 2012 — 8 лет назад всего.

                А 30 лет назад PHP еще даже не было.
                  Alexander V
                  3 часа назад
                  0
                  Это сарказм. Композер массово применяться начал совсем недавно. Не смотря на дату релиза.
              Артем
              Вчера в 21:29
              0
              MODX действительно во многом удобен и гибок, поэтому каждый из нас в свое время «не мог нарадоваться», но мы живем в 2020 году, где уже есть куда более удобные инструменты для разработки сайтов, которые экономят кучу времени и позволяют делать сайты на голову лучше. На их фоне MODX выглядит уже совершенно не вау и возвращаться к нему хочется все меньше.

              Почитайте заметки Василия про SPA — сложится понимание о том, как выглядит разработка в 2020 году и почему MODX так сильно отстает, как уже написали выше.
                Руслан Алеев
                Вчера в 21:41
                0
                Чего за удобные инструменты есть в наличии, которые сэкономят время? Можно примеры.
                  Артем
                  Вчера в 21:49
                  0
                  Фреймворки с реактивностью, например.
                    Руслан Алеев
                    Вчера в 21:57
                    +1
                    Делать на фреймворках сайты-каталоги, или визитки как-то излишне. MODX — это CMS, есть какие другие CMS, на которых реально быстрее можно сайт сделать? Мне правда интересно, может чего есть, а я не знаю.
                      Артем
                      Вчера в 22:06
                      0
                      Делать на фреймворках сайты-каталоги, или визитки как-то излишне.
                      Разумеется. Говоря про «делать сайты на голову лучше» я не подразумеваю визитки или обычные каталоги со стандартным функционалом — там и нечего делать на голову лучше. Речь про хоть сколько-нибудь сложные проекты.

                      есть какие другие CMS, на которых реально быстрее можно сайт сделать?
                      Если речь только про скорость и самые банальные сайты-визитки, то всего скорее да. Далеко ходить не нужно — какой-нибудь WP с тележкой готовых шаблонов справится с этим определенно быстрее, но вряд ли лучше, конечно.
                        Сергей Шлоков
                        Сегодня в 08:49
                        +6
                        С каких это пор разработка сайтов на фреймворках стала удобнее и экономит кучу времени? Т.е. на Ларевел удобнее делать сайт, чем на CMS с готовой архитектурой? Или разговор про js фреймворки? Так они для фронта. Они используются не вместо MODX, а вместе с MODX. Те же заметки Василия про SPA никак не отрицают использование MODX. И хочу заметить, что самописки тяжелее поддерживать. Да и архитектуру продумывать с нуля самому уж точно не быстрее. Ещё они, как правило, ограничены функциональностью — захотели добавить что-то, придётся звать программиста. Хорошо, если того же. В CMS уже много готового из коробки. И последнее, немаловажное — безопасность. В готовых системах многое уже обкатано. Разработчиков-спецов по безопасности единицы. Обычно в компаниях есть специально обученные люди. И даже при этом сайты крупнейших компаний взламывают. Можно вспомнить про соц. сеть для свингеров (забыл как называется), на которую собрали огромные инвестиции, но через простой XSS по-моему слили всю базу и опубликовали. Компания сразу закрылась. )

                        Так что, обращаясь к фрилансеру, который с нуля запилит на фреймворке сайт, заказчик получает много рисков. Исключая @Евгений Борисов ))

                        Просто пора уже перестать позиционировать MODX как панацею. Молотком можно и гвоздь забить, и шуруп, у дрова колоть. Просто эффективность будет разной. Но никто же не ругает его за это. MODX хорош и уж всяко лучше WP, но использовать его нужно с умом. Просто все системы конкуренты до сих пор развиваются, а MODX перестал.
                          Александр Мельник
                          Сегодня в 08:58
                          +1
                          MODX хорош и уж всяко лучше WP
                          Просто захотел выразить свою солидарность в этом утверждении, поскольку не переношу на дух WP и Joomla.
                          Но вынужден признать и тот факт, что любовь — это чаще всего привычка, как в жизни так и в программировании. Недавно искали разработчика по WP и общался с одним человеком, так он просто дифирамбы пел и в любви признавался WP, мол лучше систем нет в мире, все в ней идеально. А есть и более извращенцы, которые влюблены в Joomla )))
                            Артем
                            7 часов назад
                            0
                            Т.е. на Ларевел удобнее делать сайт, чем на CMS с готовой архитектурой?
                            Я вроде четко написал, что речь о фреймворках с реактивностью. Насколько мне известно, Ларавел пока не планирует переквалифицироваться во фреймворк с реактивностью.
                            Наверное, стоит перед ответом немного внимательнее читать.

                            Или разговор про js фреймворки? Так они для фронта.
                            А странички ты как рисуешь в MODX, не через него ли? Твои чанки на fenom куда выводятся, не на фронт ли? Чтобы воспользоваться преимуществами Content Management System, тебе нужно сначала создать этот контент в выбранной CMS, а потом уже управлять им. Так получается, что MODX — это уже и про фронт.

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

                            И хочу заметить, что самописки тяжелее поддерживать.
                            В какой-то степени согласен. Но все зависит от разработчика. Ты можешь наткнуться на такой сайт на MODX, где черт ногу сломит и кровь из глаз потечет. Легко будет поддерживать такой сайт? Он ведь на CMS!

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

                            И последнее, немаловажное — безопасность. В готовых системах многое уже обкатано.
                            Ну тут ты серьезно? Стоит ли мне кидать ссылку на статью, где нашли критическую уязвимость в MODX и в 1 прекрасный момент целая пачка сайтов оказалась под угрозой?
                            Стоит ли мне говорить, что если узнать о том, на какой CMS сделан сайт, то появляется потенциальная возможность использовать любую уязвимость, которая еще не была закрыта авторами CMS (вспоминаем MODX LLC, когда @Евгений Борисов пришлось демонстрировать на их собственном сайте уязвимость, чтобы они пошевелили жопами). Это безопасность?
                            Стоит ли мне говорить о древних зависимостях в MODX, в которых черт знает сколько дыр уже нашли?
                            Стоит ли мне говорить, что в самописе ты управляешь всеми зависимостями сам и следишь через тот же npm за их возможными дырами?

                            Если в %CMS_NAME% найдут уязвимость, где авторы шевелятся раз в год, то тебе придется самому изучать ее и закрывать своими силами, всего скорее ковыряя ядро. При этом на каком-нибудь форуме будут обсуждать эту уязвимость публично. Думаю, понятно, какие это будут риски для сайта.
                            Если в твоем самописе найдется уязвимость, то тебе не нужно ждать волшебной заплатки от авторов, ты берешь и исправляешь это.

                            С последним абзацем соглашусь, конечно.
                              srs
                              srs
                              4 часа назад
                              0
                              Не буду проходится по всему тексту, так как лень и не охота развивать флуд. Но такое последние тезисы очень спорны.
                              Стоит ли мне говорить, что в самописе ты управляешь всеми зависимостями сам и следишь через тот же npm за их возможными дырами?
                              Да, через npm устранять дыры, audit fix все решает. Ведь эти дыры на уровне пакетов…

                              Или вот:
                              Если в %CMS_NAME% найдут уязвимость, где авторы шевелятся раз в год, то тебе придется самому изучать ее и закрывать своими силами, всего скорее ковыряя ядро. При этом на каком-нибудь форуме будут обсуждать эту уязвимость публично. Думаю, понятно, какие это будут риски для сайта.
                              Если в твоем самописе найдется уязвимость, то тебе не нужно ждать волшебной заплатки от авторов, ты берешь и исправляешь это.
                              А если такое самописное чудо, написано человеком который только думает, что он отличный специалист. Что если это чудо передается тебе на поддержку и вдруг находится потенциальная дыра или необходимы доработки, то тебе не нужно будет изучать исходники?
                              Касаемо публичных обсуждений это может быть как минусом, так и плюсом, по этому аргумент не засчитан. У cms`ок хоть документация бывает…
                                Артем
                                4 часа назад
                                +1
                                Да, через npm устранять дыры, audit fix все решает. Ведь эти дыры на уровне пакетов…
                                Если в пакете, который ты используешься, нашлась серьезная дыра, то ты можешь хоть выпилить этот пакет и найти альтернативный. Если в условном PhpThumb найдется дыра, расскажи, пожалуйста, как ты его заменишь в MODX?

                                Что если это чудо передается тебе на поддержку и вдруг находится потенциальная дыра или необходимы доработки, то тебе не нужно будет изучать исходники?
                                Нужно. Кто-то сказал, что нет? Думаю, не нужно объяснять разницу между правкой ядра CMS и обычной правкой сурсов проекта.

                                У cms`ок хоть документация бывает…
                                Мы, по-моему, обсуждаем фреймворки, у которых документация получше CMS будет. К чему этот пункт здесь? Например, у Nuxt.js жесткая структура проекта, поэтому если тебе передают проект на Nuxt.js, то ты увидишь там знакомую структуру, логика которой подробно описана в документации. В чем тут претензия вообще?
                                  srs
                                  srs
                                  1 час назад
                                  0
                                  Если в условном PhpThumb найдется дыра, расскажи, пожалуйста, как ты его заменишь в MODX?
                                  Частично принято.
                                  Нужно. Кто-то сказал, что нет? Думаю, не нужно объяснять разницу между правкой ядра CMS и обычной правкой сурсов проекта.
                                  Так я не про парвку сурса пакета говорю, я про правку того, что написали прежние ребята используя эти пакеты. Т.е. предположим что с зависимостями все отлично, но архитектура и код говно. Предыдущие ребята просто делали как могли. В таких случаях либо переделывать, либо разбираться и то и другое долго и дорого.
                                  Мы, по-моему, обсуждаем фреймворки, у которых документация получше CMS будет. К чему этот пункт здесь?
                                  Я говорил о самописе (не cms, не фреймфорк). С фреймворками все отлично.
                                  В чем тут претензия вообще?
                                  Очень хочется пошутить на тему претензии, но шутка может показаться грубой и нечаянно обидеть. Я никаких претензий, никому не высказывал, если какие-то претензии есть, то только у тебя в голове.
                                  p.s. Мы просто говорим о разных вещах) Я говорил конкретно о самописах в то время как ты думал, что имею ввиду еще и фреймворки. Но, нет.
                                  Артем
                                  1 час назад
                                  0
                                  Так я не про парвку сурса пакета говорю
                                  Я тоже. Мы говорили о том, что где-то могут найти дыру. Если ее нашли в пакетах, то ты просто можешь заменить этот пакет на альтернативный и жить спокойно. Если ее нашли в сурсах твоего проекта, то ты просто исправляешь это. В случае с CMS ты так не сделаешь.

                                  Т.е. предположим что с зависимостями все отлично, но архитектура и код говно.
                                  Так код может быть где угодно говно — тут от инструмента не зависит. Тебе может достаться сайт на MODX, где разработчик посчитал правильным открыть modx.class.php и редактировать его под нужды сайта, вставляя в класс html-разметку.
                                  Как ты правильно подметил, тут нужно просто выкидывать и делать нормально — это касается любых инструментов.

                                  Я говорил о самописе (не cms, не фреймфорк). С фреймворками все отлично.
                                  Тогда произошло недопонимание. Так вышло, что в этой ветке комментов под самописом понимают фронтенд фреймворки типа React/Vue/Svelte. Я изначально говорил как раз о фреймворках.

                                  Я никаких претензий, никому не высказывал, если какие-то претензии есть, то только у тебя в голове.
                                  Имелась в виду претензия в сторону документаций фреймворков, конечно, а не в мою сторону лично.
                  Артур
                  Сегодня в 09:18
                  +1
                  Спасибо за ответы, хотя из них следует только то, что modx устарел морально, но не потерял удобства и функциональности.
                Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                26