efess

1. Обычно чпу нужен для страницы, которая участвует в продвижении сайта, со своими seo meta и текстом
2. Для них можно завести кастомный тип данных «результаты поиска», связав с контентными постами через «те же» постмета и термы
3. Остальные результаты «поиска» (а реально фильтрации контента) вполне могут обойтись параметрами.
4. Ну и просто ajax смена контента для обойтись без параметров никто не отменил еще

• Ответ изменён 1 месяц назад пользователем efess.

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

• Ответ изменён 1 месяц, 1 неделя назад пользователем efess.

К примеру я могу в мета найти цены с 10,50 по 11,80, а вот с термами такое сделать думаю будет очень затруднительно.

Да легко.

вариант 1. делаете таксономию, содержащую 100 границ диапазонов от 0 до 99 и вторую, содержащую 100 границ диапазонов от 0 до 0,99. назначение термов происходит автоматически при сохранении в админке поля с ценой. дальше немного логики в запросах.

вариант 2. задаете более грубые диапазоны цены. например, от 10 до 12… точность в копейки реальным пользователям не нужна. думаю даже, что вилок 1-10, 11-100, 101-1000 будет достаточно (а это уже всего три терма, вычисляемых при сохранении в админке цены товара), во всяком случае многие серьезные магазины с такими вилками работают активно

Смотрите, про отдельную таблицу… как только вы ее заводите, вам придется создавать решения ускорения выборки данных, которые находятся под капотом WP_Query и о которых мы не знаем. Навскидку могу предложить несколько вариантов бестабличного решения, в порядке усложнения реализации:

1. использовать для фильтрации цены терм ее диапазона.
2. Сделать кастомную таксономию «цена»… или две, одну для рублей, вторую для копеек, с перечислением значений.
3. впилить в таблицу wp_posts еще одно поле (с индексацией)
4. сделать на хуках и фильтрах предварительную выборку постов в базе с помощью VIEW, а сортировку уже в результатах обращения к.

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

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

Ну…. ККроме meta_query существует ещё и tax_query и много других..

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

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

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

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

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

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

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