21 марта 2018, 13:09 Отличный ответ, главное плюсов много. Не нравится что-то — не используй. А зачем тогда это все, зачем обсуждения, зачем доработки? Новости и события / Про MODX 3 39 +3
20 марта 2018, 19:41 Ну не совсем так конечно, но composer это уже большой шаг в нужном направлении. Новости и события / Про MODX 3 39 +2
19 марта 2018, 14:33 Круто что серьезная работа работа началась, однако те вещи, которые были названы в начале (проблемы XPDO, отсутствие файловых элементов, extJS и т.д.) это краеугольные камни MODX. Получается что если отказаться от XPDO например в следующем релизе, то это минимум MODX4, а вероятнее этого не произойдет никогда. Между тем это не то что нужно уже сейчас, а нужно было вчера. Проблема MODX не в том что он плох, а в том что он стремительно устаревает на уровне своих принципов. Да что говорить — автозагрузка классов в современном виде фишка 2009 года, а в MODX у нас loadClass бессменный. Новости и события / Про MODX 3 39 +1
19 февраля 2018, 16:07 Ну естественно. Вообще количество информации увеличивается, просто в ИТ сфере это очень заметно, так как происходит гораздо быстрее. Так это логично в виду темпов развития индустрии. Но, как я уже писал, в условиях появления множества идентичных технологий почему бы не остановиться на чем-то одном? Это позволит как раз добиться глубины знаний. Вопросы / Наверное это все-таки старость. 11 0
19 февраля 2018, 16:02 Ещё момент, поскольку вы недавно начали заниматься программированием может быть вам будет это полезно хотя вещь то банальная. В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах. Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация. Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка. Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL. Вопросы / Наверное это все-таки старость. 11 0
19 февраля 2018, 15:43 Глюка нет. Таково стандартное поведение MODX, не знаю уж по каким причинам — может экономия места) Вопросы / Почему MODX не сохраняет значение TV-поля — в чем "глюк"? 2 0
19 февраля 2018, 15:41 Ну вот, оказывается проблема совсем другого рода. Дело в работодателе а не в неправильном развитии индустрии) Вопросы / Наверное это все-таки старость. 11 0
19 февраля 2018, 14:41 Ну зоопарк технологий плодится по многим причинам. Есть конечно и веяния моды и желание идти в ногу со временем, но по большей части что-то новое появляется тогда когда в старом не хватает функционала или находится другой путь, кажущийся создателю более логичным и удобным. Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие. Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться) Вопросы / Наверное это все-таки старость. 11 0 1
27 декабря 2017, 15:05 Добавьтесь в скайп hetzer_tmb — попробую помочь. Вопросы / Опять pdoMenu и вложенное меню 7 0
27 декабря 2017, 14:56 Да вроде все верно. А в лимит упираться не может? Вопросы / Опять pdoMenu и вложенное меню 7 0
14 ноября 2017, 23:44 Может подход и не верный стратегически, но я бы сделал так — взял GalleryAlbums, скопировал его код в другой сниппет, скажем GalleryAlbumsFenom и в месте рендера шаблонов использовал $pdoFetch->parseChunk() вместо $modx->parseChunk(), предварительно подключив pdoTools. Вопросы / Gallery + Fenom 5 0
14 ноября 2017, 17:11 Ну на оффсайте написано 4.1.20 or newer excludes version 5.0.51 — то есть работает со всем выше 5.5 тоже. Вопросы / Кто занимается обновлениями для MODX? 8 +1
14 ноября 2017, 16:52 Вообще интересная подача: «Я знаю что MODX не работает с MySQL 5.5», а потом «Я не в курсе что поддерживает MODX». docs.modx.com/revolution/2.x/getting-started/server-requirements — как бы официальный список системных требований. Вопросы / Кто занимается обновлениями для MODX? 8 0
14 ноября 2017, 16:47 По умолчанию отправляет через mail(), однако может отправлять и через SMTP — нужно проверить системные настройки почты. В качестве хука email выступает метод email() класса fiHooks. Расположен он в файле formit/model/formit/fihooks.class.php. Вопросы / Как FormIt отправляет письма? 8 0 1
02 ноября 2017, 15:17 Почему кинуть, разговор же идет не о прекращении поддержки 2.x, а о том что будет в 3.x. Вон Evolution до сих пор существует и пользуется заслуженной любовью у многих разработчиков. Для разработчиков / Пожалуйста, давайте 2.6 будет последней версией MODX Revolution второй ветки 36 0
02 ноября 2017, 15:10 Вот ещё скажу может быть крамольную мысль — MODX не повредил бы отказ от XPDO в его существующем виде. В него запихано все что возможно и ORM и валидация и загрузка нлассов и т.д. Чтобы соответствовать современным требованиям нужно это разделять. Для разработчиков / Пожалуйста, давайте 2.6 будет последней версией MODX Revolution второй ветки 36 +1
02 ноября 2017, 15:00 Так в первую очередь нужен план действий какой-то — четкое понимание «Мы хотим видеть MODX таким-то», а уж к этому нужно прикладывать усилия разработчиков. Пока что, как я понимаю, такого плана нет — не ясно даже будет ли в следующей версии кардинальное обновление или продолжится процесс эволюции. Для разработчиков / Пожалуйста, давайте 2.6 будет последней версией MODX Revolution второй ветки 36 0
02 ноября 2017, 14:50 Да безусловно MODX нуждается в глобальной модернизации. Технологии как и тренды не стоят на месте, а основой движка остается кодовая база 2010 года. На мой взгляд как разработчика необходимы следующие изменения: — Поддержка PSR стандартов и все что с этим связано (неймспейсы, автозагрузка, composer) — Полноценный шаблонизатор из коробки (не важно smarty, fenom, twig или ещё что-то) — Отделение кодовой части от БД, что позволит нормально пользоваться системами контроля версий, а не изобретать велосипед. — Отказ от ExtJS в админке и переход на один из современных JS фреймворков. — Слабосвязанная архитектура, чтобы любую часть системы можно было легко заменить. — CLI приложение для типовых задач (парсинг схемы, создание базы компонента и т.д.) Для разработчиков / Пожалуйста, давайте 2.6 будет последней версией MODX Revolution второй ветки 36 +4
01 ноября 2017, 12:52 Как я понимаю нужно отталкиваться от визуального редактора — посмотрите имеет ли он возможность создавать кастомные вставки и если имеет то насколько сложно делать. А уж там дело техники. Вопросы / Кнопка добавления чанка в содержимое 14 0
Возможно ли реализовать возможность предоплаты за доставку на сайте? У меня Робокасса, у них вроде есть docs.robokassa.ru/ru/iframe
Редизайн сообщества На больших экранах основной текст статьи я бы сделал 18 px. Да и текст комментариев можно таким сделать. Для меня лично 16 — мелковато на больших экранах (в комментариях вообще 15 ...
MiniShop3 1.11.0 при клике на radio идет пересчет итоговой суммы в orderUI, в зависимости от способов(оплаты доставки) я так поняла. попробуй код запуска события поставить ниже чем orderUI, после
ImageOptimizer - WebP/AVIF и responsive <picture> для MODX 3 Дополнение доступно modstore.pro/packages/photos-and-files/imageoptimizer
Localizator3 для MODX 3: перевод полей и TV без отдельного context на язык, Vue 3 + PrimeV... Добавил localizator3_default_language
msInShopNotify Начиная с версии 3.0.0-beta добавлена поддержка MiniShop3 Минимальные требования: PHP 8.4 MODX 3.2 MiniShop3
MaxNotify Обновление 1.2.0-pl (03.07.2026) — добавлены уведомления о заявках FormIt через hook-сниппет `maxNotifyFormIt`; — добавлены уведомления о заявках SendIt через hook-...
[msBonus2] 1.3.0 Бонус-коды, уведомления о сгорании и совместимость с msMultiCurre... Да, планируется. Даже чуть больше, чем просто бонусная система)
Проблема MODX не в том что он плох, а в том что он стремительно устаревает на уровне своих принципов. Да что говорить — автозагрузка классов в современном виде фишка 2009 года, а в MODX у нас loadClass бессменный.
В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах.
Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация.
Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка.
Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL.
Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие.
Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться)
В качестве хука email выступает метод email() класса fiHooks. Расположен он в файле formit/model/formit/fihooks.class.php.
На мой взгляд как разработчика необходимы следующие изменения:
— Поддержка PSR стандартов и все что с этим связано (неймспейсы, автозагрузка, composer)
— Полноценный шаблонизатор из коробки (не важно smarty, fenom, twig или ещё что-то)
— Отделение кодовой части от БД, что позволит нормально пользоваться системами контроля версий, а не изобретать велосипед.
— Отказ от ExtJS в админке и переход на один из современных JS фреймворков.
— Слабосвязанная архитектура, чтобы любую часть системы можно было легко заменить.
— CLI приложение для типовых задач (парсинг схемы, создание базы компонента и т.д.)