Предложения по MODX
Коли уж так случилось, что MODX активно взялись совершенствовать, предлагаю озвучить предложения и пожелания для повышения функциональности и гибкости. Я уже давно для себя отметил несколько моментов, которые упростили бы разработку. Давайте пробежимся по ним.
Следом добавить событие OnRegisterAssets, которое вызывалось бы сразу после парсинга и перед регистрацией скриптов. Т.е. после события OnParseDocument и перед событием OnWebPagePrerender. Это дает разработчику возможность управлять подключенными скриптами и стилями — проверить, добавить, удалить и т.п. Или как вариант добавлять ассеты после события OnWebPagePrerender. Тогда новое событие не нужно.
Дальше я бы поправил логику добавления скриптов. Сейчас если в контенте нет тегов head или body, то и скрипты не подключаются. Мне кажется, что было бы лучше добавлять ассеты в начало контента, если нет тега head, и в конец контента, если нет тега body.
Это только то, что всплыло в памяти. Вспомню ещё, добавлю. Думаю, найдутся ещё предложения. Выкладывайте. Раз уж Василий попал в команду главных разработчиков MODX, то становится проще продвинуть наши пожелания.
Update 02.04.2018. Ещё вспомнил. Было бы неплохо в методе modX::addEventListener() разрешить указывать не только id плагина, но и замыкание. Т.е. не нужно создавать плагин.
Подключение скриптов и стилей
Тут нужно сделать достаточно прилично. Для начала я бы предложил заменить свойство modX::loadedjscripts на класс репозитория, у которого есть методы add, delete, has и т.д.Следом добавить событие OnRegisterAssets, которое вызывалось бы сразу после парсинга и перед регистрацией скриптов. Т.е. после события OnParseDocument и перед событием OnWebPagePrerender. Это дает разработчику возможность управлять подключенными скриптами и стилями — проверить, добавить, удалить и т.п. Или как вариант добавлять ассеты после события OnWebPagePrerender. Тогда новое событие не нужно.
Дальше я бы поправил логику добавления скриптов. Сейчас если в контенте нет тегов head или body, то и скрипты не подключаются. Мне кажется, что было бы лучше добавлять ассеты в начало контента, если нет тега head, и в конец контента, если нет тега body.
Автопубликация ресурсов
У меня, конечно, не очень большой опыт по разработке сайтов, но мне кажется, что с автопубликацией сильно перемудрили. При каждой загрузке страницы запускается целый блок проверок. Может просто изменить логику — считать опубликованными не только те, у которых стоит галка «Опубликован», но и те, у которых дата публикации меньше текущей. Это значительно упрощает логику. А ещё +1 к оптимизации.Метод modX::getResponse()
Требует рефакторинга. Вообще странно в ответ на getResponse получать TRUE или FALSE. Я понимаю, что никто в него не лазает. Да и я то в него заглянул, когда пытался подменить класс, позволяющий изменить логику формирования ответа — убирал стандартный парсер и запускал только феном.Это только то, что всплыло в памяти. Вспомню ещё, добавлю. Думаю, найдутся ещё предложения. Выкладывайте. Раз уж Василий попал в команду главных разработчиков MODX, то становится проще продвинуть наши пожелания.
Update 02.04.2018. Ещё вспомнил. Было бы неплохо в методе modX::addEventListener() разрешить указывать не только id плагина, но и замыкание. Т.е. не нужно создавать плагин.
// Сейчас так
$modx->addEventListener($event, $pluginId)
// Разрешить так
$modx->addEventListener($event, function(){...})Это во мне программист так говорит. ) Комментарии: 58
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
П.С. Вот интересно, если бы у Майкла Видениуса было больше детей, сколько бы SQL серверов он написал? У него 2 девочки по имени My и Maria (MySQL и MariaDB).
miniShop2 на то и был создан, чтобы добавить коммерческий функционал в систему и дальше расширять её как душе угодно.
Данный топик скорее предполагает обсуждение и предложение идей общих для движка в целом.
Можно сделать всё как там. Загрузка изображений к записи, медиабиблиотека и прочее.
Это в большей степени относиться к текстовым редакторам. Естественно для шаблона так и останутся тв поля.
Бонусом он содержит еще и редактор изображения прямо в админке после загрузки
В какой то ветке читал, что хотят редактор текста какой то стандартный по умолчанию добавить, вот к нему библиотеку медиа было бы как раз замечательно.
А хочется из коробки простое, готовое решение для добавления картинок в контент.
В том то и прелесть MODX'a что можно делать так, как тебе нужно и не уткаться в постоянные ограничения. К примеру один мой клиент с новостным сайтом наоборот прется от файловой структуры, они аккуратно кладут по папочкам все фотографии, фотографии с путином в папочку — putin, корабли в корабли и т.д.
Всем не угодить делая ограничения, а вот развязав руки — можно
Сейчас можно сделать, как душа желает. А для вашего способа подойдет отдельный плагин, сниппет и т.п., т.е. все то что расширяет базовый функционал.
Реализовать медиатеку как в wordpress'е модулем не сильно сложно, было бы кому и было бы зачем.
На данный момент главная проблема modx'a в том, что отсутствует адекватная документация для разработчиков, если ты хочешь реализовать свой тип тв, то тебе не в доки надо лезть, а читать либо исходники других дополнений, либо исходники modx. А была бы нормальная документация с описанием как и что взаимодействует между собой там бы уже и ленивые разработчики разного качества подтянулись бы. А то многие ответы на вопросы до сих пор приходится вычитывать в вопросах на mpdxpro, а в англоязычном сегменте они вообще не выбиваются
Именно по этому мы кстати можем наблюдать феномен на modxpro что если кто-то постит хоть чуть-чуть адекватный и полезный простой и очевидный кусок кода по расширению стандартного функционала эта заметка сразу набирает с десяток избранного, потому что новые разработчики собирают информацию по крупинкам и каждый объясненный кусок кода — как глоток свежего воздуха.
Я собственно сам собирал так информацию и до сих пор собираю и/или пользуюсь уже написанными статьями.
Чтобы не быть голословным попробуйте загуглить на английском как добавить поля пользователя в modx, чтобы они не в json хранились а адекватно и в таблице выводились, не думаю что вам даже упоминание такого вопроса встретится. По этому функционал расширения огромен и прост, но вот описать его в доках никто совершенно не спешит
Посмотрите доку vuejs, посмотрите доку пресловутого октября, да там есть ответы на любые вопросы и никто не пишет статьи о том, как расширить профиль пользователя, просто потому, что незачем об этом писать, в доках все написано
Уф, что-то меня понесло, простите за огромную пелену текста
Очень хотелось бы доработать модуль личных сообщений в modx, а то у него даже событий нет. Ну или хотя бы не выпиливать его. Очень часто используется когда делаешь проект с социальным функционалом
2. не все умеют с posgres работать
Недавно переносил Yii2 с posgres у провайдера Jino. Не понятно, что они там намудрили в своих конфигурациях, но подключиться так и не смог. В итоге проще было настроить VDS.
Вопрос/предложение: почему в админке MODX Revo ссылки на чанки и другие элементы в дереве странно генерятся, их нельзя открыть колесом мыши (ссылки, как я понимаю, скриптовые). Будет ли такое в MODX 3 или возможно это исправить, есть в планах?
Спасибо за ответ!
Надеемся, будет в MODX 3 работать.
Ctrl + клик, конечно, работает, но это уже усложнение.
В любом случае, спасибо за помощь. Вы, если время будет, посмотрите тоже, возможно issue все-таки некорректное.
Заранее спасибо.
Я думаю, все же стоит оценить самые скачиваемые дополнения и, возможно, внедрить какие-либо полезные функции в MODX3.
Персональный список таких дополнений, которых, по-моему, не хватает:
— AutoTemplate — о нем выше;
— filetranslit — транслитерация загружаемых файлов, есть транслитерация псевдонимов, почему не быть и файлам;
— UpgradeMODX — обновление MODX;
— hideSource — скрытие медиа-источников файлов из дерева;
— minifyHTML — удаление лишних табов и пробелов при генерации шаблона в браузере;
— MinifyX (Возможно) — объединение и сжатие js и css.
Еще хотелка — возможность создавать конфиги настроек, например, для пакетной загрузки компонентов — один раз загрузил нужные компоненты, экспортировал конфиг на будущее и в будущем загружаешь конфиг и дополнения ставятся сразу толпой :) для системных настроек тоже такую возможность внедрить бы (опять же функционал такой в MODX уже есть, но работает в «Политиках доступа»).
Я понимаю про концепцию MODX как CMF и про излишний функционал, но, повторюсь, некоторые компоненты логичны и жаль, что их нет из коробки. К примеру, виджет обновления MODX в 3 версию внедряют (по скринам хотя бы :) ).
Надеюсь, вы прислушаетесь к комментариям, и MODX воспылает новыми красками! Спасибо за ваш труд!
p.s. Стоит помимо популярных и скачиваемых дополнений также оценить и рынок конкурентов из популярных CMS/CMF.
minifyHTML, minifyx — однозначно мимо, потому что это не ворпрес, где все уже сделали за тебя, сиди пиши свои мнения на весь мир. Кто-то может вообще все собирать с помощью gulp/grunt/webpack, зачем ему тянуть вместе с системой подделие, которое уже пару лет как не поддерживается нормально (движок минификации на php в minifyx).
Установка пакетов за раз вероятно будет когда-то, но там есть свои ньюансы. Но уже сейчас это можно делать с помощью gitify.
В будущих версиях MODX планируется удалить еще больше вещей, которые не являются остро необходимыми для ядра. Сейчас кодовая база самого MODX слишком большая и поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет. Если все эти хотелки внедрять в ядро, это увеличивает энтропию, а как следствие больше ошибок, больше граничных случаев, запросов от пользователей и прочее, что делает разработку самой системы очень медленно, да и мелкую фичу можно ждать полгода, потому что кроме нее еще десяток крупных, а релизить MODX только ради мелочи — очень затратно. Все же я придерживаюсь принципов бережливого производства, так как они самые адекватные и понятные всем.
Вынесение пользовательких функций в отдельные дополнения выгодно по многим пунктам: даст возможность более плотно работать над ядром системы и быстрее выпускать по настоящему стоящие релизы, не отвлекаясь на поддержку пользовательских функций; отдельные дополнения можно релизить независимо и выпускать патчи и новые возможности намного быстрее, чем релизы ядра; легче привлечь людей в качестве мейнтейнеров на отдельные дополнения, которые будут заниматься только ими и активно их развивать (т.е. делегация полномочий). Надеюсь моих доводов достаточно для понимания текущей ситуации.
Возможно, кстати, стоит расширить базовый шаблон, который ставится с MODX и там указывать популярные дополнения, которые помогут новичкам освоиться на старте (редакторы, меню, ресурсы, формы) или виджет популярных дополнений, чтобы в админке был предустановлен.
Система же качественная, но неприветливая уж.
Спасибо, Иван, за информацию.
Неограниченные домены и поддомены
Неограниченные разработчики
Использование в коммерческих продуктах
Интеграция с загружаемыми продуктами
Интеграция с продуктами SaaS
Интеграция с продуктами с открытым исходным кодом
Насколько знаю сообщество разработчиков Yii купили такую лицензию и это позволяет пользоваться редактором в Yii проектах
PS могу ошибаться