efess

Полки можете поменять местами. Но не товары, взятые на разных полках, выложенные в витрину, по факту их принадлежности к полкам. Можете наклеить на них ярлычки (postmeta) и разложить по порядку по ярлычкам

у многих курьёз, как кто только не пытался придумать визуальную адаптацию под них,

Тоже мне, бином Ньютона ))

Горизонтальный свайп картинок, лучше одного товара… когда посетитель видит основное фото и край второго. Тут главное не вешать на страницу лошадиного веса слайдер, а ограничиться хорошим простеньким самописом.

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

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

Видите, meta_value, в котором хранятся обычно данные, по каким вы можете сделать сортировку в запросе, не имеет индекса. Это не просто так, в meta_value обычно хранится такое большое количество вариативных значений, что его индексация не имеет смысла — индексы таблицы распухнут, а скорости выборки/сортировки не добавится. В результате имеем полнотекстовый поиск/сортировку по таблице, и при ее серьезном размере (а она обычно растет быстрее остальных таблиц, и ее размер в несколько гб — это больно) — тормоза при запросе к базе. Поэтому везде, где можно, лучше использовать все-таки таксономии. Ну в вашем случае, если не будете в постмета пихать что попало, если база будет относительно невелика — можно и пренебречь.

Лет 10 назад может и дорого было… А сейчас процессоры и память копейки стоят. Прокси ещё подключи, браузерные заголовки нормально пробрось, кэш научи сбрасывать… Не стоит того.

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

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

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

закинуть на отдельный VPS хотя бы медиа контент, уже часть нагрузки будет снята.

да нет там никакой нагрузки — апач запрос получил — файл отдал, та же статика, даже меньше, потому что без движка. если прокси стоит, дак вообще… lazy load на порядок полезней

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

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

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

Идеологически правильно предоставлять пользователю структурированную информацию, а не вываливать все, что у вас есть. В магазинах ведь есть отдельные полки для групп товаров, и здесь то же самое. То есть нужно давать, например, ссылки на группы Рулевая… Ведущая… или фильтровать чекбоксами. А сортировка — это достаточно убогий тип фильтрации. Тем более тематическая сортировка — неизвестно ведь, что важнее посетителю.