на какой-то из версий этот компонент мешал нормально перенести сайт

Мне кажется, или тема довольна сильно влияет на производительность!?

да, чет читал что modx все равно сперва ищет в базе, потом уже файл и заново типа кеш генерит

Там ещё и плагин есть? Я не знаю, не ставил)) У меня тоже свой скрипт)))

Я когда курс по модекс смотрел, изучал модекс, буквально на той неделе, и там об этом говорилось. Что тема так себе.

ну человек слайдер на collection делает, ему уже не помочь))

Предлагаю обсудить, почему migx это плохо... И чем его заменить

Мне кажется, или тема довольна сильно влияет на производительность!?

было что-то, давно @Sentinel7 с тобой вроде натыкались на это во время переноса

migx топчик

Ты не шаришь

казах спит уже давно и во сне хромированную гантельку видит

да, чет читал что modx все равно сперва ищет в базе, потом уже файл и заново типа кеш генерит

Объелся протеина и спит

было что-то, давно @Sentinel7 с тобой вроде натыкались на это во время переноса

Всё правильно, так и есть. Поэтому реквестирую @iOnePrihod в #StaticElementsLive добавить функцию отвязки всех статичных элементов от базы в 1 клик (но сохранять список какие были статичными и путь+источник) и кнопочку "сделать опять статичными". Чтобы можно было на продакш-сайте отрубать от файлов, а на дев-копии оставлять. Заранее извиняюсь что не виде PR. Я вообще сегодня seo-шник и настолько глубоко не умею в код ((

Но я надеюсь, что Саша это уже пофиксил 🤷‍♂

У меня есть пара тестов, на которые я потратил кучу времени, чтобы убедиться в приросте производительности при отключении статичных элементов (просто галочки поснимал со всех шаблонов и чанков), в рамках экспериментов на пути к идеальному #pagespeed вот поделюсь пожалуй, хотел на #MODCONF отложить, но раз к слову пришлось: Выигрыш при отключении статических элементов для кэшированной отдачи страницы (цифры - время в миллисекундах ответа бекенда) на одном жирном проекте с MODX 2.8.4 Страница текстовая простая /pro (контент текст с 1 фото + pdoMenu текстовое) 194 → 156 = 0,8x = -19% Сборная страница прайс-листа на продукцию и услуги /price (Текст, куча тегов FastField, куча фото, pdoResources, 2 слайдера) ~291 → ~159 = 0.55x = -45% Список отзывов (тексты, видео, галереи с фото, pdoPage) /otzivy ~297 → ~191 = 0,63х = -35% Страница текстовая простая (pdoResources список текстовых блоков + pdoResources слайдер) /services ~213 → ~197 = 0.92x = -7.5% Страница портфолио ~272 → ~191 = 0,70х = -29,7% Главная ~256 → ~191 = 0,74x = -25% Важного замечание для тех, кто «использует только файловые чанки» и думает, что его проекта это не касается: весь тестируемый проект собран на fenom include и FILE либо INLINE чанках, то есть нефайловые используются только там, где файловые не поддерживаются (например в imagePlus snippet)

до тебя я и не знал что есть такой доп))

У меня есть пара тестов, на которые я потратил кучу времени, чтобы убедиться в приросте производительности при отключении статичных элементов (просто галочки поснимал со всех шаблонов и чанков), в рамках экспериментов на пути к идеальному #pagespeed вот поделюсь пожалуй, хотел на #MODCONF отложить, но раз к слову пришлось: Выигрыш при отключении статических элементов для кэшированной отдачи страницы (цифры - время в миллисекундах ответа бекенда) на одном жирном проекте с MODX 2.8.4 Страница текстовая простая /pro (контент текст с 1 фото + pdoMenu текстовое) 194 → 156 = 0,8x = -19% Сборная страница прайс-листа на продукцию и услуги /price (Текст, куча тегов FastField, куча фото, pdoResources, 2 слайдера) ~291 → ~159 = 0.55x = -45% Список отзывов (тексты, видео, галереи с фото, pdoPage) /otzivy ~297 → ~191 = 0,63х = -35% Страница текстовая простая (pdoResources список текстовых блоков + pdoResources слайдер) /services ~213 → ~197 = 0.92x = -7.5% Страница портфолио ~272 → ~191 = 0,70х = -29,7% Главная ~256 → ~191 = 0,74x = -25% Важного замечание для тех, кто «использует только файловые чанки» и думает, что его проекта это не касается: весь тестируемый проект собран на fenom include и FILE либо INLINE чанках, то есть нефайловые используются только там, где файловые не поддерживаются (например в imagePlus snippet)

ну это приличный прирост

О, норм. хорошо что ими не пользуюсь. только include fenom

Да конечно, не обольщайся)) Тестируемый проект этот весь на 100% собран на include fenom в том то и дело)) Пруфскрин шаблона страницы /price (одна из самых медленных в тесте)

а почему Limit = 0 ? в снипетах.

Да конечно, не обольщайся)) Тестируемый проект этот весь на 100% собран на include fenom в том то и дело)) Пруфскрин шаблона страницы /price (одна из самых медленных в тесте)

а почему Limit = 0 ? в снипетах.

Очевидно, я хочу вообще все цены на странице всех цен) (это сайт услуг и чуть-чуть товаров) и без пагинации. А что смущает?

Очевидно, я хочу вообще все цены на странице всех цен) (это сайт услуг и чуть-чуть товаров) и без пагинации. А что смущает?

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

Ну это для TVшек актуально, а на полях ресурсов что я выиграю? Чуть меньше оперативки потратится разве что, и то только при первой загрузке до формирования MODX-кэша.

Ну это для TVшек актуально, а на полях ресурсов что я выиграю? Чуть меньше оперативки потратится разве что, и то только при первой загрузке до формирования MODX-кэша.

ну человек слайдер на collection делает, ему уже не помочь))

И специально для вас нашел чанк слайдера на #Collections 🚀 Убедился за одно что он тоже на правильных FILE чанках

еще кучка запросов ради слайдера) вместо того чтобы сделать 1 запрос и распарсить json ))

Да уже обсуждали. Легло в кэш и забыл. А полумёртвые хостинги с медленной БД уже забыл когда видел) Не тормозит, зато никаких foreach в коде, и все фичи pdoTools (например раздельный cacheKey для МОБ и ПК версий, слабо с MIGX?)

Оооочень сомнительно. кеш? в чем плюсы? Моб, ПК ? че-то не понятно в чем плюсы? И смысл для слайдера URL ?

Оооочень сомнительно. кеш? в чем плюсы? Моб, ПК ? че-то не понятно в чем плюсы? И смысл для слайдера URL ?

ну и загрузить, например 3 слайда одним махом - не получиться. )

Ага, лови MIGX-адепта! )) По URL: Ну я например в шаблоне ресурса одного слайда вывожу превью того как нарезаны картинки, только в хайрезе, а не как в админке. А на каких-то проектах слайдер сразу состоит из страниц акций, то есть выборка для слайдера из тех же ресурсов что и из, например, услуг, но TV-шки другие используются для вывода (без content например)

Не очень понял этот пункт. Всё что надо делать, получается. Это же стандартный функционал pdoTools который вдоль и поперёк отработан примерно всеми. Если уточнишь, смогу ответить (не холивара ради)

Ну, тут специфика конкретного проекта. Возможно в данном случае оправданно. Ведь я за слайдер в понимании: банер-картинка, текст, кнопка-ссылка. Без страниц. И нет смысла тащить ресурсы под это дело.

Ну 1 ресурс - одно фото. В плане что увеличивается время заполнения для менеджера.

А потом начинается, левый или правый, (текст слева, кнопка справа, и наоборот), а давайте на моб. сократим текст (нет, не просто truncate а чтоб контентщик выбрал нужные слова). А для этого слайда дизайнер 2 кнопки нарисовал. А что плохого использовать ресурсы там, где это задумано в MODX? В изначальной концепции Ресурс != Страница!

А, да не, это надуманное. В Collections тоже есть инлайн-редактирование из грида, также как и в MIGX.

Я не говорю что плохо. Я хочу понять в чем преимущество. Поля в migx добавляются без проблем и функционал лево-право и чё хочешь. Цвет даже (в моих темах будет это для слайдов). Поэтому и заинтересовался.

Всё, нашёл килл-фичу: в слайдах-ресурсах ещё возможность снятия с публикации, публикации по расписанию и даже прав доступа на каждый слайд из коробки! #collections - мощ! Делай #слайдер правильно! (но есть и другие правильные варианты 😂 )

Ниразу доступ не нужен был. Если это прям нужно в проекте, то вопросов нет. Но это уже попахивает каким то крупным проектом со своей уникальной логикой. В таком случае киллер фитча в мигиксе - загрузка фоток слайдера одним махом - мультизагрузка. ) Про публикации - и в migx есть... Это просто 0 или 1. Не аргумент. Можно и удаленные и прочее.

По времени? Не проблема условие составить.

Я могу сказать что мне не проблема сделать фронтенд-загрузчик фоток (есть готовый даже), который из каждой фотки создаёт ресурс и к каждой несколько полей. Но это такое же "не то же самое", что и "условие публикации самому составить". Из коробки ресурсы дают и другие бенефиты, потому что MODX так устроен, здесь ресурс — основная учётная единица!

Я могу сказать что мне не проблема сделать фронтенд-загрузчик фоток (есть готовый даже), который из каждой фотки создаёт ресурс и к каждой несколько полей. Но это такое же "не то же самое", что и "условие публикации самому составить". Из коробки ресурсы дают и другие бенефиты, потому что MODX так устроен, здесь ресурс — основная учётная единица!

Ну для меня главный плюс это выборка через понятный и гибкий pdoResources вместо этих foreach fromJSON стрёмных прямо в шаблоне)

Да я понимаю это все. Я пытаюсь найти реальные плюсы другого подхода. Если требуется 3..4 поля для слайда.

Так и минусы же есть) Ты всё хочешь больше плюсов, а про минусы не спрашиваешь)) Ресурс обязывает иметь pagetitle, его надо выдумывать для слайда, что можно притянуть за уши как когнитивную нагрузку для контент-менеджера))) А при сохранении duplcate uri проверка, сам понимаешь что иногда будет дубль и не даст сохранить. Решается пакетом customurls например. Ещё на новом проекте создать нужно несколько TV-шек в то время как MIGX можно JSON-ом весь залить. Настройки #collections тоже можно экспортировать-импортировать, но TV-шки придётся создавать руками (хотя есть варианты, я просто не использую Packman, может и другие способы есть)

Я не говорю что плохо. Я хочу понять в чем преимущество. Поля в migx добавляются без проблем и функционал лево-право и чё хочешь. Цвет даже (в моих темах будет это для слайдов). Поэтому и заинтересовался.

А ещё #MIGX -конфиги как версионируются? По-моему никак, даже #VersionX не ловит их. А это получается слабоподконтрольная точка отказа в проекте. В идеале чтобы в #git -е было вообще всё, что не относится к контенту. В #collections -конфигах ведь только отображение, его не так опасно потерять, а TV-шки #VersionX -ируются, чего не скажешь про migx-поля. #контрольверсий важен! Если не хочешь через пол года охренеть от своего же проекта...

Да минусы есть и там и там. Думал есть какой то плюс который поменяет мое мировоззрение. ) Ну да ладно. Не суть в общем то.

Который прям заставит отказаться от MIGX для слайдера, наверное такого и нет и я уж точно не буду топить за то чтобы отказываться. Просто кое кто, не будем показывать пальцем, прям высмеивает идею делать #слайдер на #collections , считая что #MIGX единственно правильный путь, а я вот из дофигилиона проектов ни разу не делал на #MIGX а всегда на #collections и поэтому уверенно заявляю, что есть альтернативы и у них даже есть преимущества! Но конечно, главный недостаток #collections для тех, кто всегда пользовался #MIGX это необходимость преодоления боязни нового) Ровно как и наоборот. Я юзаю #MIGX для прайс-листов, но слайдер не мой выбор. Лучше уж #BannerY )) К стати почему его никто не рассматривает для слайдера? Там есть преимущества, которых ни в migx, ни в collections из коробки нет! Я раньше юзал, но выборку через pdoResources хочу, а loadModels мне сложно))

Там просто нет простого расширения полей.... Редактор текста нужно прикручивать самому... Ну короче, не модно. В общем, пора закругляться... Поспать хоть чуть чуть )))

Согласен, без редактора текста печально, я и забыл уже. Да, доброй ночи!

всем привет подскажите пожалуйста можно ли както сократить сие "чудо")? чтоб поменьше было запусков, ато как по мне громоздко слишком) выгоднее будет сниппет с циклом сделать ?

всем привет подскажите пожалуйста можно ли както сократить сие "чудо")? чтоб поменьше было запусков, ато как по мне громоздко слишком) выгоднее будет сниппет с циклом сделать ?

Переписать на fenom