2 часа назад
не помогло к сожалению, подскажите пожалуйста, в каком направлении вы бы продолжили искать?
msOneClick. Ошибка, не появляется модальное окно 2
Вчера в 15:29
Разобрался!
Использую редактор Tinymcerte
В системных настройках нужно отключить Относительные URL!
Теперь обычные внутренние ссылки корректные...
Jevix чудит 8
Вчера в 14:35
Николай, низкий поклон за время и труд, тебе и всем ребятам, кто приложил руки.
Очень-очень жду и уповаю на ms3, буду рад чем-либо помочь (тестирован...
MiniShop3 - 1.0.0-alpha 16
Вчера в 13:12
Спасибо, точно, забыл про это поле. Может есть пример сниппета на запись в это поле? Не могу понять как обратиться к нужному файлу, получить его поле ...
[UserFiles] - Файлы пользователя. 188
Вчера в 11:13
Спасибо добрейшее. А тип поля «Текстовая область», как-то можно сменить на TinyMCE RTE?
[ExtraFields] Поле "не появляется/не включить" в "Настройках форм/шаблон Това... 2
10 декабря 2024, 22:05
[[!msOptions?
&options=`mount`
&tpl=`tpl.msOptions.Roman...
[Решено] Сортировка параметров опции 2
10 декабря 2024, 17:06
да, работает, спасибо!
[msProducts] Как вывести в каталог только те товары, у которых есть изображения в галерее? 2
09 декабря 2024, 12:36
Я разобрался :)
Достаточно было тупо < img… > обернуть в маркированный список, получилось как то так:
{
"header": "Изобр...
Как отобразить в таблице родительского MIGX изображения из дочернего MIGX? 8
07 декабря 2024, 12:38
Эта проблема возникает если у вас версия mysql ниже версии 8 из за этого не создается таблица при установке.
[SendIt 2.0.0] Пагинация и обновлённая загрузка файлов 25
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал MODX, когда для этих условий не было аналогов, но это время прошло. Быть разработчиком и не развиваться — значит, быть плохим разработчиком.
Я верю в это сообщество, но, думаю, что правильный путь выбрать будет очень непросто. Некоторые решения (REST-расширение, например) вполне очевидны, но вот выбранная архитектура может больно «аукнуться» позже. Трендовые решения (React/Vue/Angular/Ember) дают быстрый старт, но имеют пару фатальных недостатков — они «смертны» (да, Реакт и Вью через 3 года станут жуткими архаизмами или на столько видоизменятся, что будут иметь мало общего с тем, что вы видите сейчас) и однонаправленны — выбирая архитектуру под React, мы практически полностью (ну или в большей степени) делаем её несовместимой с Angular/<ваш любимый фреймворк>.
Я не смею предлагать, но вижу наиболее сильный формат в поиске решений — дебаты. Т. е. должен возникнуть положительный конфликт, когда все заинтересованные стороны (а не один разработчик) принимают решение о векторе (или закладывают точку для ветвления/масштабирования). Своего рода роадмап, но не решений, а обсуждений: RestAPI — на каком языке (может, это вообще микросервис на Go или SaaS-платформа)? Какой API-фреймворк? Работа через API MODX или напрямую с БД? Типизация? Валидация? SDK? Админка — а что на счёт Headless CMS? Может, какой-то DSL для обратной совместимости? React/Vue/Angular/etc? Монорепозиторий (lerna + yarn workspace) или независимые компоненты?. Плюс такого подхода ещё и в том, что параллельно с доводами в пользу своего решения «кандидат» сам будет заинтересован в наибольшей понятности своего предложения. И сразу понятно, какие компоненты системы могут кем курироваться. Стабильно в течение какого-то времени (неделя? месяц?) «комитет» принимает решение (после того, как споры вокруг какой-то темы стабилизировались (утихли или разделилился на несколько лагерей).
Со своей стороны предлагаю опыт в клиентской и серверной шаблонизации, DSL, SSR, сборщиках, компонентном подходе и вёрстке, UX/UI.
Так это не имеет отношения к MODX. Вон на nevatrip.ru у меня 100k записей, а оптимизацией даже не занимался ещё.
А вы попробуйте использовать «Битрикс-подход» к этой проблеме — оплатите работу профессионала. Уверен, будет дешевле аналогичного решения от 1С.
Потому что «взять и переписать» звучит для них гораздо страшнее, чем «мы оставим всё, как есть, но теперь ваши странички будут открываться быстрее и без перезагрузки».
Потому что MODX хоть и достаточно монолитный (в сравнении с всякими Phalcon'ами, Laravel'ами и прочими Yii на composer'ах), но значительная часть архитектуры более чем оправданная, особенно учитывая, сколько времени CoreTeam поддерживает обратную совместимость 2.x-поколения.
Конечно, многое зависит от опыта и «базы» — я пришёл в разработку именно благодаря MODX, он (она?) обеспечил планомерный и правильный «вход в профессию» („Привет!“ «разработчикам мышкой» на WordPress). Тем, кому «повезло» больше и имеет за плечами фундаментальные знания паттернов, алгоритмов и других «интегралов», конечно, сподручнее использовать что-то более низкоуровневое, но это не принижает заслуги MODX и сообщества.
Сейчас у меня есть удачный кейс, когда шаблонизатор отделён от данных дополнительным слоем абстракции, где происходит нормализация и весь шаблон на выходе имеет JSON-структуру, на которую применяются чистые функции. Что это даёт (при наличии опыта и понимания):
* отделение логики от представления, возможность фронт-енду и бэк-енду работать параллельно и независимо, использование mock-объектов для данных, если сервер ещё не готов, бэк-енду не нужно думать о том, как «сверстать всё это, чтобы было красиво» — он работает над правильной архитектурой;
* более высокая скорость отдачи страницы на клиент (да, MODX можно ещё ускорить, и от этого аж уши закладывает!), при этом рендер по-прежнему происходит на сервере (привет, SEO), а при правильном выборе шаблонизатора, код может быть изоморфным — получаете SPA-приложение «из коробки» (те самые «реактивные интерфейсы»). Если не ошибаюсь, Николай @real-Fi1osof Ланец неоднократно рассказывал, что шаблонизатор MODX — bottleneck производительности;
* реиспользование. У MODX в этом плане пока слабо, он довольно монолитный, но фронтендовский компонентный подход во всей красе.
Из возможных минусов: наиболее быстрый шаблонизатор сейчас написан на JavaScript, попытки переписать XJST на PHP, Python и даже Go потерпели фиаско. Сейчас JS, де-факто, стандарт в мире фронт-енд-разработки (рубисты больше не фыр-фыр), т. е., конечно, я не предлагаю начинающим разработчикам делать лендинги на таком стеке, но любой более-менее сложный конкурентный (!) проект, который вы планируете поддерживать или цикл разработки которого больше 5-6 месяцев неизбежно будет обрастать легаси-кодом и лишь правильная декомпозиция позволит этого избежать.
Т. е., если рассматривать MODX исключительно как админку + RESTFul API-сервер, можно наконец-то забыть об оверхеде переноса и отладки клиентской части сайта/приложения на MODX, потому что MODX будет заниматься только тем, чем и должен заниматься бэкенд — данными, не тратя время на шаблонизацию.
— lavkaschastya.com/
— www.schastye.com/
React, нестандартные наборы товаров, вёрстка любой сложности. Хочу ещё попробовать полностью отказаться от MODX-шаблонизатора, но подходящего проекта пока не было.