Предложения по 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
Думаю, самый ожидаемый ответ на все пожелания — modx.pro/news/14903/#comment-95329
Это же не багфиксы. Эти предложения нужно для начала обсудить.
Ну тут действительно по вопросам ядра нет смысла что-то расписывать, разве что обсудить. Может кто и возьмётся за написание PR'ов
Можно написать простой прототип решения, чтобы было о чем общаться предметно, а уже потом его развить. Так то у команды есть свой план, остальные вольны делать что хочется. Я например пилю поддержку postgres (не самая простая задачка), кому интересно: github.com/modxcms/xpdo/pull/136/files
Ну Postgres для MODX наверно великоват будет. Вообще в рекомендациях указана MariaDB.
П.С. Вот интересно, если бы у Майкла Видениуса было больше детей, сколько бы SQL серверов он написал? У него 2 девочки по имени My и Maria (MySQL и MariaDB).
П.С. Вот интересно, если бы у Майкла Видениуса было больше детей, сколько бы SQL серверов он написал? У него 2 девочки по имени My и Maria (MySQL и MariaDB).
MariaDB, как и Percona (и mysql) — это одно семейство, причем практически взаимозаменяемое (если использовать общий стандарт, а не фичи отдельных движков). Postgres не великоват, но в 21 веке не иметь поддержки pgsql — форменный бардак. Правда иногда случаются и «веселые» вещи, когда нужно поддерживать обе ветки (это я про свой рабочий OS проект).
Чего больше всего не хватает в modx так это унифицированного интерфейса для прикрутки платежных систем. Minishop и модули к нему не в счет. К примеру я бы сделал модули платежей к tickets, для платного размещения постов, например при построении сайта объявлений. Да и в целом это должно не зависеть от модулей. А сейчас как я вижу, такой интерфейс есть только у minishop
Слишком частный случай, чтобы реализовывать это в универсальной CMS из коробки.
miniShop2 на то и был создан, чтобы добавить коммерческий функционал в систему и дальше расширять её как душе угодно.
Данный топик скорее предполагает обсуждение и предложение идей общих для движка в целом.
miniShop2 на то и был создан, чтобы добавить коммерческий функционал в систему и дальше расширять её как душе угодно.
Данный топик скорее предполагает обсуждение и предложение идей общих для движка в целом.
В том то и дело, что интерфейса как такового нет вовсе, модуль на бронирование комнат с онлайн оплатой, базируется на интерфейсах minishop2. Разве это норма, разве это частное решение.
Относительно базового функционала фреймворка, да, частное. То, что вы хотите, реализуется отдельным компонентом.
Если сравнивать с вордпрессом, то здесь не хватает работы с изображениями.
Можно сделать всё как там. Загрузка изображений к записи, медиабиблиотека и прочее.
Можно сделать всё как там. Загрузка изображений к записи, медиабиблиотека и прочее.
А ТВ с типом «Изображение»?
Тв с типом «Изображение» надо добавить в поля, присвоить к шаблону, драг-дроп не работает(вроде). А если надо несколько изображений? Простенькая галерея? Как быстро найти изображение от другой записи? Медиабиблиотека для всех загруженных файлов.
Это в большей степени относиться к текстовым редакторам. Естественно для шаблона так и останутся тв поля.
Это в большей степени относиться к текстовым редакторам. Естественно для шаблона так и останутся тв поля.
Большую часть хотелок вами описанных покрывает image+
Бонусом он содержит еще и редактор изображения прямо в админке после загрузки
Бонусом он содержит еще и редактор изображения прямо в админке после загрузки
Общую библиотеку медиа он не даёт. Опять же это доп поле, если мне нужно в одной записи 2 картинки вставить в текст, а в другой 10.
В какой то ветке читал, что хотят редактор текста какой то стандартный по умолчанию добавить, вот к нему библиотеку медиа было бы как раз замечательно.
В какой то ветке читал, что хотят редактор текста какой то стандартный по умолчанию добавить, вот к нему библиотеку медиа было бы как раз замечательно.
если мне нужно в одной записи 2 картинки вставить в текст, а в другой 10Используй MIGX и подключи туда это доп. поле. А на счет медиа библиотеки не знаю что мешает сделать источник файлов на какую то одну папку и как раз при открытии файлового менеджера менеджер будет видеть все фотографии в этой папке, другое дело что все превью каждый раз генерируются заново, это не хило так бьет по нагрузке, а некоторые хостинги вообще банят за ДДОС
Вот именно, подключи мигикс, настрой и прочее.
А хочется из коробки простое, готовое решение для добавления картинок в контент.
А хочется из коробки простое, готовое решение для добавления картинок в контент.
Так и modx не совсем CMS, раньше modx позиционировал себя как CMF, но видимо понятие CMF никому не было понятно, по этому поменяли на CMS.
В том то и прелесть MODX'a что можно делать так, как тебе нужно и не уткаться в постоянные ограничения. К примеру один мой клиент с новостным сайтом наоборот прется от файловой структуры, они аккуратно кладут по папочкам все фотографии, фотографии с путином в папочку — putin, корабли в корабли и т.д.
Всем не угодить делая ограничения, а вот развязав руки — можно
В том то и прелесть MODX'a что можно делать так, как тебе нужно и не уткаться в постоянные ограничения. К примеру один мой клиент с новостным сайтом наоборот прется от файловой структуры, они аккуратно кладут по папочкам все фотографии, фотографии с путином в папочку — putin, корабли в корабли и т.д.
Всем не угодить делая ограничения, а вот развязав руки — можно
Вы правы, MODX как раз для этого и сделан, но моё предложение никак не отменяет вашего подхода. Просто это базовый функционал, который используется на 90% сайтов. И хотелось бы его видеть при установке системы.
Это на ваших 90% сайтах используется, а на моих 100% не используется и не будет, пока обязаловом не введут.
Сейчас можно сделать, как душа желает. А для вашего способа подойдет отдельный плагин, сниппет и т.п., т.е. все то что расширяет базовый функционал.
Сейчас можно сделать, как душа желает. А для вашего способа подойдет отдельный плагин, сниппет и т.п., т.е. все то что расширяет базовый функционал.
подключи мигикс, настрой и прочее.Самое главное, что это делается в два клика и 10 минут, а вот представь сколько придется потратить времени чтобы обойти медиатеку и вернуть файловую структуру? Явно не 10 минут
Философия MODX изначально была и есть в модульной структуре, и именно это реализовано я считаю отлично, по умолчанию даже редактор кода не идет в коробке так то. Что происходит с wordpress'ом от десятка плагинов? Wordpress начинает дико лагать от админки до фронта, что происходит с modx? А ничего не происходит т.к. он изначально делался по типу «нужен такой функционал которого не хватает? Напиши его или установи готовое решение»
Реализовать медиатеку как в wordpress'е модулем не сильно сложно, было бы кому и было бы зачем.
На данный момент главная проблема modx'a в том, что отсутствует адекватная документация для разработчиков, если ты хочешь реализовать свой тип тв, то тебе не в доки надо лезть, а читать либо исходники других дополнений, либо исходники modx. А была бы нормальная документация с описанием как и что взаимодействует между собой там бы уже и ленивые разработчики разного качества подтянулись бы. А то многие ответы на вопросы до сих пор приходится вычитывать в вопросах на mpdxpro, а в англоязычном сегменте они вообще не выбиваются
Именно по этому мы кстати можем наблюдать феномен на modxpro что если кто-то постит хоть чуть-чуть адекватный и полезный простой и очевидный кусок кода по расширению стандартного функционала эта заметка сразу набирает с десяток избранного, потому что новые разработчики собирают информацию по крупинкам и каждый объясненный кусок кода — как глоток свежего воздуха.
Я собственно сам собирал так информацию и до сих пор собираю и/или пользуюсь уже написанными статьями.
Чтобы не быть голословным попробуйте загуглить на английском как добавить поля пользователя в modx, чтобы они не в json хранились а адекватно и в таблице выводились, не думаю что вам даже упоминание такого вопроса встретится. По этому функционал расширения огромен и прост, но вот описать его в доках никто совершенно не спешит
Посмотрите доку vuejs, посмотрите доку пресловутого октября, да там есть ответы на любые вопросы и никто не пишет статьи о том, как расширить профиль пользователя, просто потому, что незачем об этом писать, в доках все написано
Уф, что-то меня понесло, простите за огромную пелену текста
Реализовать медиатеку как в wordpress'е модулем не сильно сложно, было бы кому и было бы зачем.
На данный момент главная проблема modx'a в том, что отсутствует адекватная документация для разработчиков, если ты хочешь реализовать свой тип тв, то тебе не в доки надо лезть, а читать либо исходники других дополнений, либо исходники modx. А была бы нормальная документация с описанием как и что взаимодействует между собой там бы уже и ленивые разработчики разного качества подтянулись бы. А то многие ответы на вопросы до сих пор приходится вычитывать в вопросах на mpdxpro, а в англоязычном сегменте они вообще не выбиваются
Именно по этому мы кстати можем наблюдать феномен на modxpro что если кто-то постит хоть чуть-чуть адекватный и полезный простой и очевидный кусок кода по расширению стандартного функционала эта заметка сразу набирает с десяток избранного, потому что новые разработчики собирают информацию по крупинкам и каждый объясненный кусок кода — как глоток свежего воздуха.
Я собственно сам собирал так информацию и до сих пор собираю и/или пользуюсь уже написанными статьями.
Чтобы не быть голословным попробуйте загуглить на английском как добавить поля пользователя в modx, чтобы они не в json хранились а адекватно и в таблице выводились, не думаю что вам даже упоминание такого вопроса встретится. По этому функционал расширения огромен и прост, но вот описать его в доках никто совершенно не спешит
Посмотрите доку vuejs, посмотрите доку пресловутого октября, да там есть ответы на любые вопросы и никто не пишет статьи о том, как расширить профиль пользователя, просто потому, что незачем об этом писать, в доках все написано
Уф, что-то меня понесло, простите за огромную пелену текста
Очень дельное предложение! Очень удобно в текстовом редакторе вордпресс добавлять изображения в текст. В Modx этого очень не хватает.
Так поставьте CKeditor или аналогичный и добавляйте, в чём проблема?:)
Отпишусь и я:
Очень хотелось бы доработать модуль личных сообщений в modx, а то у него даже событий нет. Ну или хотя бы не выпиливать его. Очень часто используется когда делаешь проект с социальным функционалом
Очень хотелось бы доработать модуль личных сообщений в modx, а то у него даже событий нет. Ну или хотя бы не выпиливать его. Очень часто используется когда делаешь проект с социальным функционалом
Он (модуль сообщений) будет выпилен как раз в угоду тому, чтобы запилить нормальные сообщения в виде отдельного компонента, который можно обновлять и дорабатывать и обновлять независимо от самого MODX.
До сих пор не запилили. И поводов особо не видно.
У меня в планах сразу после postgres. Желающие помочь (описать, что должно быть в компоненте сообщений обязательно, что хотелось бы и т.д.) — you're welcome!
Так Modstore спонсирует разработки, напишите им и в вперёд!:)
Вопрос не в помощи, я могу и так написать, вопрос в пожеланиях по функция, что в нем должно быть.
У меня в планах сразу после postgres.Не перебор?
Вы о чем?
О Postgres
А почему это перебор?
1. не на всех хостингах есть
2. не все умеют с posgres работать
Недавно переносил Yii2 с posgres у провайдера Jino. Не понятно, что они там намудрили в своих конфигурациях, но подключиться так и не смог. В итоге проще было настроить VDS.
2. не все умеют с posgres работать
Недавно переносил Yii2 с posgres у провайдера Jino. Не понятно, что они там намудрили в своих конфигурациях, но подключиться так и не смог. В итоге проще было настроить VDS.
Справедливости ради, надо отметить, Jino весь такой, через одно место замороченный.
Таки SQLSRV который сейчас поддерживается, но используется еще реже, чем postgres, то у последнего больше прав. Касательно хостинга, он тоже бывает разный и не исключено, что есть клиенты, у которых сервисы построены на pgsql, но создать простой сайт рядом они не могут, потому что нужно ставить еще и mysql.
Я говорю о массовом применении. 99% это MySQL и обычный шаред.
Далеко не 99%, а узость применения только на MySQL как раз и не дает использовать MODX шире, хотя возможности и запросы есть.
Здравствуйте, Иван, спасибо за ваш вклад в MODX 3, приятно осознавать, что проект оживает!
Вопрос/предложение: почему в админке MODX Revo ссылки на чанки и другие элементы в дереве странно генерятся, их нельзя открыть колесом мыши (ссылки, как я понимаю, скриптовые). Будет ли такое в MODX 3 или возможно это исправить, есть в планах?
Спасибо за ответ!
Вопрос/предложение: почему в админке MODX Revo ссылки на чанки и другие элементы в дереве странно генерятся, их нельзя открыть колесом мыши (ссылки, как я понимаю, скриптовые). Будет ли такое в MODX 3 или возможно это исправить, есть в планах?
Спасибо за ответ!
Ctrl+клик
В любом динамическом дерево ссылки быдут скриптовыми. Но насколько я помню, этот момент исправляли и открыть средней кнопкой в новом окне можно (могу ошибаться, у меня нет колеса на мыши, потому не пользуюсь).
Нет, не исправили, в каждой версии первым делом проверяю, пока не работает :) Где-то читал, что это в google chrome что-то поменяли.
Надеемся, будет в MODX 3 работать.
Ctrl + клик, конечно, работает, но это уже усложнение.
Надеемся, будет в MODX 3 работать.
Ctrl + клик, конечно, работает, но это уже усложнение.
Если это поменяли в google chrome, то работать не будет и в 10 версии. Выше головы то не прыгнешь. Вообще хорошо бы написать issue на эту тему на github — github.com/modxcms/revolution/issues/new, чтобы не потерялось.
Вроде решение есть и внедрено github.com/modxcms/revolution/pull/13103 но так и не работает, по-моему, или я чего-то не понимаю.
Проверьте настройки мыши у себя в системе, может кнопка переопределена и какой-то другой код возвращает или может плагин какой стоит. Тут вариантов может быть много, наверняка сказать сложно.
Спасибо, проверю обязательно, но, по-моему, я проверял на разных мышах и разных машинах — не работает.
В любом случае, спасибо за помощь. Вы, если время будет, посмотрите тоже, возможно issue все-таки некорректное.
Заранее спасибо.
В любом случае, спасибо за помощь. Вы, если время будет, посмотрите тоже, возможно issue все-таки некорректное.
Заранее спасибо.
Здравствуйте, Иван, давеча мы обсуждали дополнительный функционал и об ненужности внедрения излишнего функционала в MODX3, однако я имел в виду то, что есть популярные компоненты, которые не «усложняют», а скорее «исправляют» MODX, к примеру, есть дополнение «AutoTemplate» которое при создании нового ресурса ставит ему шаблон как у его соседних ресурсов (если таковых нет, то шаблон родителя) — крайне логичное поведение по-моему.
Я думаю, все же стоит оценить самые скачиваемые дополнения и, возможно, внедрить какие-либо полезные функции в MODX3.
Персональный список таких дополнений, которых, по-моему, не хватает:
— AutoTemplate — о нем выше;
— filetranslit — транслитерация загружаемых файлов, есть транслитерация псевдонимов, почему не быть и файлам;
— UpgradeMODX — обновление MODX;
— hideSource — скрытие медиа-источников файлов из дерева;
— minifyHTML — удаление лишних табов и пробелов при генерации шаблона в браузере;
— MinifyX (Возможно) — объединение и сжатие js и css.
Еще хотелка — возможность создавать конфиги настроек, например, для пакетной загрузки компонентов — один раз загрузил нужные компоненты, экспортировал конфиг на будущее и в будущем загружаешь конфиг и дополнения ставятся сразу толпой :) для системных настроек тоже такую возможность внедрить бы (опять же функционал такой в MODX уже есть, но работает в «Политиках доступа»).
Я понимаю про концепцию MODX как CMF и про излишний функционал, но, повторюсь, некоторые компоненты логичны и жаль, что их нет из коробки. К примеру, виджет обновления MODX в 3 версию внедряют (по скринам хотя бы :) ).
Надеюсь, вы прислушаетесь к комментариям, и MODX воспылает новыми красками! Спасибо за ваш труд!
p.s. Стоит помимо популярных и скачиваемых дополнений также оценить и рынок конкурентов из популярных CMS/CMF.
Я думаю, все же стоит оценить самые скачиваемые дополнения и, возможно, внедрить какие-либо полезные функции в MODX3.
Персональный список таких дополнений, которых, по-моему, не хватает:
— AutoTemplate — о нем выше;
— filetranslit — транслитерация загружаемых файлов, есть транслитерация псевдонимов, почему не быть и файлам;
— UpgradeMODX — обновление MODX;
— hideSource — скрытие медиа-источников файлов из дерева;
— minifyHTML — удаление лишних табов и пробелов при генерации шаблона в браузере;
— MinifyX (Возможно) — объединение и сжатие js и css.
Еще хотелка — возможность создавать конфиги настроек, например, для пакетной загрузки компонентов — один раз загрузил нужные компоненты, экспортировал конфиг на будущее и в будущем загружаешь конфиг и дополнения ставятся сразу толпой :) для системных настроек тоже такую возможность внедрить бы (опять же функционал такой в MODX уже есть, но работает в «Политиках доступа»).
Я понимаю про концепцию MODX как CMF и про излишний функционал, но, повторюсь, некоторые компоненты логичны и жаль, что их нет из коробки. К примеру, виджет обновления MODX в 3 версию внедряют (по скринам хотя бы :) ).
Надеюсь, вы прислушаетесь к комментариям, и MODX воспылает новыми красками! Спасибо за ваш труд!
p.s. Стоит помимо популярных и скачиваемых дополнений также оценить и рынок конкурентов из популярных CMS/CMF.
Нет, не стоит. Вернее какие-то моменты не мешало бы, да, вроде того же обновления. Но AutoTemplate — частный случай, что делать, если мне нужно наоборот? Ставить AntiAutoTemplate? filetranslit вероятно, хотя тоже спорно.
minifyHTML, minifyx — однозначно мимо, потому что это не ворпрес, где все уже сделали за тебя, сиди пиши свои мнения на весь мир. Кто-то может вообще все собирать с помощью gulp/grunt/webpack, зачем ему тянуть вместе с системой подделие, которое уже пару лет как не поддерживается нормально (движок минификации на php в minifyx).
Установка пакетов за раз вероятно будет когда-то, но там есть свои ньюансы. Но уже сейчас это можно делать с помощью gitify.
В будущих версиях MODX планируется удалить еще больше вещей, которые не являются остро необходимыми для ядра. Сейчас кодовая база самого MODX слишком большая и поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет. Если все эти хотелки внедрять в ядро, это увеличивает энтропию, а как следствие больше ошибок, больше граничных случаев, запросов от пользователей и прочее, что делает разработку самой системы очень медленно, да и мелкую фичу можно ждать полгода, потому что кроме нее еще десяток крупных, а релизить MODX только ради мелочи — очень затратно. Все же я придерживаюсь принципов бережливого производства, так как они самые адекватные и понятные всем.
Вынесение пользовательких функций в отдельные дополнения выгодно по многим пунктам: даст возможность более плотно работать над ядром системы и быстрее выпускать по настоящему стоящие релизы, не отвлекаясь на поддержку пользовательских функций; отдельные дополнения можно релизить независимо и выпускать патчи и новые возможности намного быстрее, чем релизы ядра; легче привлечь людей в качестве мейнтейнеров на отдельные дополнения, которые будут заниматься только ими и активно их развивать (т.е. делегация полномочий). Надеюсь моих доводов достаточно для понимания текущей ситуации.
minifyHTML, minifyx — однозначно мимо, потому что это не ворпрес, где все уже сделали за тебя, сиди пиши свои мнения на весь мир. Кто-то может вообще все собирать с помощью gulp/grunt/webpack, зачем ему тянуть вместе с системой подделие, которое уже пару лет как не поддерживается нормально (движок минификации на php в minifyx).
Установка пакетов за раз вероятно будет когда-то, но там есть свои ньюансы. Но уже сейчас это можно делать с помощью gitify.
В будущих версиях MODX планируется удалить еще больше вещей, которые не являются остро необходимыми для ядра. Сейчас кодовая база самого MODX слишком большая и поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет. Если все эти хотелки внедрять в ядро, это увеличивает энтропию, а как следствие больше ошибок, больше граничных случаев, запросов от пользователей и прочее, что делает разработку самой системы очень медленно, да и мелкую фичу можно ждать полгода, потому что кроме нее еще десяток крупных, а релизить MODX только ради мелочи — очень затратно. Все же я придерживаюсь принципов бережливого производства, так как они самые адекватные и понятные всем.
Вынесение пользовательких функций в отдельные дополнения выгодно по многим пунктам: даст возможность более плотно работать над ядром системы и быстрее выпускать по настоящему стоящие релизы, не отвлекаясь на поддержку пользовательских функций; отдельные дополнения можно релизить независимо и выпускать патчи и новые возможности намного быстрее, чем релизы ядра; легче привлечь людей в качестве мейнтейнеров на отдельные дополнения, которые будут заниматься только ими и активно их развивать (т.е. делегация полномочий). Надеюсь моих доводов достаточно для понимания текущей ситуации.
Да, комментарии понятны. «Делегация полномочий» — подход грамотный, но и не всегда полезный. «поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет.» — нет энтузиастов в виду того, что порог вхождения большой, а большой он и в том числе из-за того, что функционал делегирован. Помню, при первом знакомстве с MODX после попсовых CMS я не мог понять как меню вывести, я даже не знал откуда можно скачать дополнения (на тот момент MODX ставился без шаблона с полезными ссылками, просто белый экран, что смущало) :) Ну это к слову…
Возможно, кстати, стоит расширить базовый шаблон, который ставится с MODX и там указывать популярные дополнения, которые помогут новичкам освоиться на старте (редакторы, меню, ресурсы, формы) или виджет популярных дополнений, чтобы в админке был предустановлен.
Система же качественная, но неприветливая уж.
Возможно, кстати, стоит расширить базовый шаблон, который ставится с MODX и там указывать популярные дополнения, которые помогут новичкам освоиться на старте (редакторы, меню, ресурсы, формы) или виджет популярных дополнений, чтобы в админке был предустановлен.
Система же качественная, но неприветливая уж.
Да, я это не дописал в первом комментарии. Это пока не принято официально, но было мое предложение во время обсуждения, чтобы сделать системные дополнения (типа автообновление, редактор картинок, система сообщений и прочие) предустановленными при установке самого MODX (не так как в Evo, когда идут вместе в архиве, а именно через API установщика). Так же этот список должен быть конфигурируемым, чтобы его можно было переопределить в момент установки (положить свой файл с конфигом, например). Меня потом дополнили, что в случае ошибок с сетью или когда установка делается offline без доступа к репозиторию, выводить сообщение о невозможности установить дополнения и пропуску этого шага.
Здорово! Было бы круто, если внедрите в итоге, огонь. Ну и виджет дополнений стоит сделать, тем более, что там есть менее полезные виджеты, типа «погода» (судя по скринам).
Спасибо, Иван, за информацию.
Спасибо, Иван, за информацию.
Меня лично все устраивало и в старых сообщениях, очень понятная и простая модель, не хватало разве что уведомления о новых сообщениях при входе в админку и событий стандартных по типу до сохранения/после сохранения, также было бы круто добавить в найстройки настройку класса-обработчика
Мечтаю о таком редакторе в modx imperavi.com/redactor/ даже бы скинулся на покупку лицензии
Лицензия на 1 сайт. Как понять скинулся бы?
OEM
Неограниченные домены и поддомены
Неограниченные разработчики
Использование в коммерческих продуктах
Интеграция с загружаемыми продуктами
Интеграция с продуктами SaaS
Интеграция с продуктами с открытым исходным кодом
Насколько знаю сообщество разработчиков Yii купили такую лицензию и это позволяет пользоваться редактором в Yii проектах
PS могу ошибаться
Неограниченные домены и поддомены
Неограниченные разработчики
Использование в коммерческих продуктах
Интеграция с загружаемыми продуктами
Интеграция с продуктами SaaS
Интеграция с продуктами с открытым исходным кодом
Насколько знаю сообщество разработчиков Yii купили такую лицензию и это позволяет пользоваться редактором в Yii проектах
PS могу ошибаться
Разве не он? www.modmore.com/redactor/
Пользуйтесь, зачем мечтать? www.modmore.com/redactor/
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.