wfoojjaec

Помню, заменял его на BreadCrumb. Разницы в скорости там серьёзной нет.

Дизайнеры тоже люди. Работать за «спасибо» и «на репутацию» никто не обязан, и стоит отвыкать от этого стереотипа в любой деятельности. Качественный продукт никто не будет раздавать бесплатно, если сам «покупатель» не является продуктом.

На счёт дизайна — нет смысла тратить на это столько усилий. Это админка, а не свистопердящий фронтенд. Достаточно какого-нибудь шаблона за 5$ с themeforest по тегу dashboard, подогнанного под нужды MODX.

На мой взгляд это упирается совсем в другую, более глобальную проблему — ExtJS. Отказаться от него сложно. Использовать bootstrap (для которого уйма дешёвых и красивых решений для админок) в паре с ним крайне затруднительно. Лучшее, что можно безболезненно натянуть на текущую админку — это тему для ExtJS с мелкими правками для разного разрешения, где это вообще возможно (почти нигде. т к ExtJS почти всегда меряет размеры скриптами).

Для отображния я его использовал. Но встречал в документации ссылку на получение данных через AJAX. Вполне возможно там есть поддержка всех плюшей именно на стороне сервера. Но тут не могу гарантировать, надо копать.

Возможно стоит воспользоваться этой штукой для рендеринга таблиц. У них много полезностей, в том числе локализация, поддержка различных версий bootstrap, различные поиски-сортировки-экспорты, AJAX обновление из указанного источника.

https://datatables.net/

Из того, что у них особенно понравилось — хорошо оптимизирован поиск и сортировка. Неплохо выгребает даже на 200к записей.

Небольшой отзыв из личного опыта о таком методе. Очень не советую по ряду причин.
Обрабатывать HTML, как и любую структуру, регулярками, а не полноценным построением подели через парсинг, очень плохая идея. Про это неоднократно пишут. Возможны самые различные последствия, самые вкусные из которых:

1. Повреждение преформатированного текста, где важен каждый символ.
2. Повреждение ld+json разметки, json-аттрибутов, шаблонов, где пробелы тоже часто играют роль.
3. Повреждение JavaScript кода, в частности регулярных выражений, строк и логики (потеря перевода строки может приводить к нерабочему коду).

И другие подобные прелести.
Лучше пользоваться услугами CDN, если уже совсем лень.

Всё-таки оставлю и своё мнение по этому поводу.

Ultron, как и любой маркетплейс, берёт с продавца комиссию. Если я правильно помню, то цифры следующие (пример из письма от вс, 26 янв., 10:12):

ДО 50 ПРОДАЖ — 50%
60% ОТ 51 ДО 100 ПРОДАЖ
70% ОТ 101 И БОЛЕЕ

Требований по обновлению самих сборок к разработчикам они не предъявляют (исходя из того же письма). Поэтому не понятно, кто в конечном счёте должен следить за актуальностью версий дополнений и движкой в сборках. Вероятно сам покупатель (есть ли об этом какое-то предупреждение на видном месте или в справочном разделе — хз).

К чему это я. Маркетплейс, конечно, хороший, но конкретно этот момент продуман ну очень хреново. Лично я отказался сотрудничать с ними, но не по этой причине. К сожалению платные компоненты включить в сборку у них возможности нет. Было бы неплохо, если бы комиссии действительно оправдывали себя (защита покупателя, накопительные скидки, техническая поддержка и прочие, обязательные, для современного мира плюшки).

Немного неожиданно, ну ок, по-порядку.

Как обычно автор о том как работает, что внутри его компонента происходит ничего не написал. На тестовом модхост тестить бессмыслено.

Буду рад, если смогу как-то улучшить описание. Тестирование на modhost не такой и бессмысленный процесс.

Все думаю стоит ли взять или нет. Достаточно сниппет в шаблон куда-нибудь сверху добавить или я чего-то не понимаю?!

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

Набрать свыше 90 крайне сложно. Вроде бы даже главная Google с этим не справляется, как бы иронично это не звучало.

Ранее тестировали PageSpeed для Nginx. Из проблем — это не промышленное решение. Он либо есть у хостера либо его нет. Если сервер свой, то надо ставить руками. И обычным apt-get install к сожалению обойтись не выйдет, нужно угробить часы админского времени. Из-за этого пришлось от него отказаться.

Следующим шагом был выбор провайдера. Именно он влияет на рейтинг «первого байта». И к сожалению скорость для РФ не значит скорость для Google. Оптимальным показался именно выбор провайдера на территории Европы с использованием CDN. Выбор очень широкий и качество достойное.

Ленивая загрузка изображений делалась через bLazy (есть и другие, превосходные аналоги).

Сжатие спева делалось через MinifyX. Он офигенно справляется, если все ресурсы уже скачаны и разложены по папочкам.
Позже накопился ворох плагинов на JavaScript, которые приходилось менять или обновлять. Аналогично было и с версиями Bootstrap. Пришлось переехать на NodeJS (webpack, gulp, тысячи их). Всё офигенно, но зачем тогда MODX?..
Отдельных мучений стоила минификация HTML. В некоторых случаях CDN давал не самые подходящие результаты, и Google не пропускал, предлагая сжать HTML ещё лучше, а минификаторы из официальных репозиториев могли похвастаться одной и той же \s+ регуляркой, которая съедала всё на своём пути.

Google тем временем требовал ещё и грамотно поставить теги preconnect и использовать async/defer.

Плюнули. Написали свою шарманку для склеивания скриптов и стилей в кучу. Завернули туда же минификатор. Назвали PageSpeed.

Следующим шагом был webp. Первой попыткой была конвертация картинок «на лету». Стало понятно, что этот идиотизм проживёт до первой тысячи картинок или посетителей, и память превратится в склероз.
Второй — попытка делать отконвертированные копии при загрузке или по cron-у. Ждать час или каждую минуту сканировать кучу каталогов.
Третьей — очередной модуль для Nginx.
В итоге — конвертация с сохранением во временный кэш, лежащий рядом с движком. Расход места возрастает примерно на половину веса картинок, но зато конвертация идёт «по требованию». Если какую-то картинку вдруг вздумалось поменять — кэш улетает по кнопке и конвертация сама пройдёт заново.
Огромный минус этой фичи — зачем людям сохранять картинку с котиком на свой телефон в формате webp? А ведь получив ссылку на такую картинку выбора у человека уже нет — его браузер сказал, что он поддерживает webp.

Фреймворки тоже используют ООП-модель. Они рассматривались.

В итоге был выбор: или искать спеца под нужный фреймворк или немного допилить уже известный движок. Второе оказалось проще.

Любой сайт нужно обслуживать, если это не визитка на чистом HTML.

Тестировалось на 1-2 миллионах ресурсов. Системные настройки приходилось тщательно обрабатывать напильником.

Из того, что падает и невозможно использовать:
1. mSearch2 — первый камень в огород Наумкина. Но и его понять можно — предусмотреть идеальный вариант для всех сайтов задача непосильная.
2. pdoPage — катастрофа астрономических масштабов. Постраничная навигация тоже делается своими силами. Всему виной передача всех id в дочерний сниппет.
3. Стандартная постраничная навигация в товарной админке сжирает RAM. но частично работоспособна.

Из серьёзных ограничений:
1. msProducts нужно запускать аккуратно, хорошо подбирая для него параметры.
2. Максимум 1 TV, максимум 1 свойство у товаров miniShop2 (если оно есть у всех товаров). Всё из-за особенностей таблиц БД.
3. Успех запуска pdoMenu сильно зависит от дерева категорий.

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

Время генерации страницы каталога в среднем около 3 секунд, что для автомобилистов вполне терпимо.

Тот самый пример.