понял, будем разбираться, спасибо

попробовал просто вывести слайдер на отдельной странице без modx, все работает... чудеса какие-то

попробовал просто вывести слайдер на отдельной странице без modx, все работает... чудеса какие-то

а у вас феном может включен на страницах..?

Может кто подсказать, как сделать сортировку на странице по клику? Один кликаем сортировка по названию ASC, второй раз меняется направление сортировки Нашел такое &sortBy=`{ '[[!#GET.sort:is=`name`:then=`pagetitle ASC`:else=`pagetitle`]]' , 'DESC'}` <a href="[[~[[*id]]]]?sort=name">По названию</a> Но не работает

через pdoPage вывожу

Все понял, мне нужно было сортировать по алфавиту В параметрах pdoPage параметр такой &sortdir=`[[!#GET.sort]]` &sortby=`pagetitle` И ссылка такая <a href="[[~[[*id]]]]?sort=ASC">AZ</a> <a href="[[~[[*id]]]]?sort=DESC">ZA</a>

все работает. Через jquery в зависимости от скрытого поля переключаю кнопку с сортирвокой

а у вас феном может включен на страницах..?

fenom_parser отключен. на всякий случай заключил все в ignore - ничего не поменялось

fenom_parser отключен. на всякий случай заключил все в ignore - ничего не поменялось

Ну тогда: Сделайте бекар файлов, базы если его нет. Удалите все и поставьте модикс с нуля чистый - для проверки. Если он не заработает - то хостинг. Если заработает, то что-то с файлами.

Ребят. Привет. Скажите, кто сталкивался и что делать. На сайте 37к товаров, и 700 опций. Т.е опций товара достаточно много из-за этого загрузка страницы при подключениее msproduct невероятно долгая. Я нашел способ использовать обычные pdoresurces и через fastfield вытаскивать цену и картинку. Но это же колхоз) как быть в такой ситуации. И вопрос а modx вообще способен такое переваривать (а точнее minishop2)

Допустим при запуске mfilter2 ограничить выборку только по нужным нам полям, а не вытягивать весь объект с инфой.

Допустим при запуске mfilter2 ограничить выборку только по нужным нам полям, а не вытягивать весь объект с инфой.

Так помогает вызов mfilter2 некэшируемым. Но сами понимаете, что при возврате дефолтнвх значений при фильтрации все равно идет новый запрос в БД. А не поиск по кэшу

Так помогает вызов mfilter2 некэшируемым. Но сами понимаете, что при возврате дефолтнвх значений при фильтрации все равно идет новый запрос в БД. А не поиск по кэшу

Тогда тут еще вопрос назревает. А можно ли кэшировать результаты выборок в фильтрации?

Ребят. Привет. Скажите, кто сталкивался и что делать. На сайте 37к товаров, и 700 опций. Т.е опций товара достаточно много из-за этого загрузка страницы при подключениее msproduct невероятно долгая. Я нашел способ использовать обычные pdoresurces и через fastfield вытаскивать цену и картинку. Но это же колхоз) как быть в такой ситуации. И вопрос а modx вообще способен такое переваривать (а точнее minishop2)

Долго? Сколько сек из Кеша и сколько после очистки Кеша?

40 сек и 0,5 соответственно

Ой

Наоборот)

Тогда тут еще вопрос назревает. А можно ли кэшировать результаты выборок в фильтрации?

В бд есть настройка - кешировать запросы бд

У меня в 502 ошибку падает сайт после этого

40 сек и 0,5 соответственно

Те после очистки Кеша 40 сек открывается страница???????

Ага

Вот пример на одной из страниц каталога с mfilter2 SQL: 17.7387 s (1702), PHP: 2.3028 s, MEM: 24 576 kb, ALL: 20.0416 s (database) SQL: 0.0255 s (99), PHP: 0.2149 s, MEM: 16 384 kb, ALL: 0.2404 s (cache)

Вот пример на одной из страниц каталога с mfilter2 SQL: 17.7387 s (1702), PHP: 2.3028 s, MEM: 24 576 kb, ALL: 20.0416 s (database) SQL: 0.0255 s (99), PHP: 0.2149 s, MEM: 16 384 kb, ALL: 0.2404 s (cache)

Проверьте индексы в бд.... ТК это очень долго.

Может индексы слетели....

Проверьте индексы в бд.... ТК это очень долго.

Я немного туп. Можете подсказать как это сделать?) А точнее как должно быть правильно

Хотя я сейчас сам попробую разобраться)

главное услышать, что это не нормально

Ну я особо отклонений не вижу, в сравнении с другими сайтами

А это нормально, что в таблице содержатся пустые значения в кологке "value"

?

Норм. Проверьте таблицы site content

Ms product

Что-то я не восем понимаю как уникальных значений в modx_site_content может быть всего 20, когда на сайта 30к товаров, в этом и есть косяк?

Что-то я не восем понимаю как уникальных значений в modx_site_content может быть всего 20, когда на сайта 30к товаров, в этом и есть косяк?

Ну, как то что то не то...

Надо попробовать проверить таблицы...

Во вкладке операции

Для всех 3 стутус OK

Так же анализ таблицы ещё выполните

И оптимизировать таблицу

Можно ещё обновить кеш таблицы сделать.

том тоже норм, сейчас попробую оптмизировать, все 3 таблицы? или конкретную?

Да, все.... Хотя бы с этого начать.

А у вас выделенный или шаред хостинг?

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

оптимизировать нужно не таблицы, а сам код - SQL: 17.7387 s (1702) . 1702 запроса - как то сильно дофига

все ок. это innoDB оно не поддерживает.

[[mFilter2? &class=`msProduct` &element=`msProducts` &showHidden=`false` &suggestions=`false` &values_delimeter=`^` &aliases=` ms|price==price, msoption|color==color, msoption|kolichechestvo_skorostey==kolichechestvo_skorostey, msoption|kolischestvo_filtrov==kolischestvo_filtrov, msoption|moshnost==moshnost, msoption|ploshad_poseysheniya==ploshad_poseysheniya, msoption|scorost_ochistki_vozduha==scorost_ochistki_vozduha, msoption|uroven_shuma==uroven_shuma ` &filters=` msoption|ploshad_poseysheniya, ms|price:number ` &limit=`39` &sort=` ms|price:ASC ` &tpl=`catalog_item` &tplFilter.outer.price=`tpl.mFilter2.filter.slider` &tplFilter.row.price=`tpl.mFilter2.filter.number` &tplFilter.row.color=`tpl.mFilter2.filter.color` &tplFilter.row.product_actions=`tpl.mFilter2.filter.action` &tplFilter.row.style=`tpl.mFilter2.filter.style` ]] Да у меня обычный вызов

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

&limit=39 - поставьте 10....15 :)

Я вот фиг знает что мы понаделали, но стало Разработка сайта: REDBE AGENCY SQL: 0.7482 s (1757), PHP: 2.7600 s, MEM: 24 576 kb, ALL: 3.5082 s (database)

Сейчас еще проверю

не вызов оптимизировать, а код))

Я вот фиг знает что мы понаделали, но стало Разработка сайта: REDBE AGENCY SQL: 0.7482 s (1757), PHP: 2.7600 s, MEM: 24 576 kb, ALL: 3.5082 s (database)

стало лучше?

SQL: 17.7387 s (1702), PHP: 2.3028 s, MEM: 24 576 kb, ALL: 20.0416 s (database) или SQL: 0.7482 s (1757), PHP: 2.7600 s, MEM: 24 576 kb, ALL: 3.5082 s (database) Определенно), проверяю на других категориях

для интереса можете посмотреть опять что там с индексами стало и весом Таблиц и индекса (мб).

Ну в принципе по сравнению что было - сайт просто летает) только я дурак и надо было поэтапно смотреть что помогло

Ну в принципе по сравнению что было - сайт просто летает) только я дурак и надо было поэтапно смотреть что помогло

вроде же только в БД копались... 3 операции сделали.

Да, стало по-другому

да, видимо индексы и в правду слетали...

Блин, спасибо огромное, а то я уже разочаровался в силе MODx

как увидили в данном случае модикс не причем особо. :) но для php 2 сек - многовато. ааа у вас MODX парсер только... тогда - есть куда оптимизировать :)

оптимизировать нужно не таблицы, а сам код - SQL: 17.7387 s (1702) . 1702 запроса - как то сильно дофига

это нормально для сайта в котором MODX теги везде... там как бы такая картина всегда. :))) это дичь, конечшно же и никто не спорит.

это нормально для сайта в котором MODX теги везде... там как бы такая картина всегда. :))) это дичь, конечшно же и никто не спорит.

конечно же это не нормально)) модикс теги или феном / или не важно.

Как в input'e получить сам элемент через this? пробую вывести через консоль, он весь документ в this помезщает...

Нативный javascript

как увидили в данном случае модикс не причем особо. :) но для php 2 сек - многовато. ааа у вас MODX парсер только... тогда - есть куда оптимизировать :)

Там я сделал очень навороченный сайт, так что 2 секунды приемлемо

Как в input'e получить сам элемент через this? пробую вывести через консоль, он весь документ в this помезщает...

ну вы бы хоть код привели...

ну вы бы хоть код привели...

const selectElement = document.getElementsByTagName('input'); selectElement[0].addEventListener('keyup', (e) => { console.log(this); });

ну все верно вы цепляетесь ко всем INPUT

const selectElement = document.getElementsByTagName('input'); selectElement[0].addEventListener('keyup', (e) => { console.log(this); });

e.target нужно вместо this

да просто у стрелочных функций своего контекста нет) а есть родительский

e.target нужно вместо this

Спасибо

конечно же это не нормально)) модикс теги или феном / или не важно.

Кстати. А на феноме же дольше обработка идет? Я просто тестировал у меня так показывало.

Кстати. А на феноме же дольше обработка идет? Я просто тестировал у меня так показывало.

долше не должна идти.

Там же еще один цикл подключается, если посмотреть по логике

да, пару раз там срабатывает. Просто на феноме многие вызовы и манипуляции можно делать менее затратно. пример getImageList для MIGX. для вывода поля. если через СНИППЕТ делать это может быть куча доп запросов. А на феноме - это может быть просто foreach. особенно если картинок в нем нет.