CyMPuK: На здоровье) Если в дальнейшем понадобится несколько фильтров - там сам $query->set() будет уже другим. Создавайте тогда новый вопрос и приглашайте ответить.
CyMPuK: Стоп, последний вопрос. У вас только поле "бренд"? Может есть смысл его сделать таксономией? Это чисто вопрос правильной архитектуры. Или есть еще другие параметры, а "бренд" - это лишь один пример?
CyMPuK: ну это я вам и ответил, что query_posts использовать нельзя, потому что эта функция в первую очередь как раз пагинацию и ломает. Теперь у меня вопрос почему у вас это обернуто в функцию go_filter() и как вы ее вызываете?
Правильно ли я понимаю, что вам необходимо в каталоге иметь выпадающий список брендов, и при выборе должна происходить сортировка постов по выбранному бренду? С перезагрузкой страницы или без нее?
Rou1997: Ох...
Еще раз повторяю - у вас кони-люди смешались. Вы путаете базовые понятия, что говорит о недостаточном опыте и упоротости в некоторые "идеологически якобы правильные" решения.
Во-первых, MVC != ООП. Даже более того, в 99,99% случаев Controller в MVC берет на себя слишком много, что перечит базовому Single Responsibility Principle, а размазывание одного логического объекта по всем трем составляющим - модели, контроллере и view, перечит другому принципу - энкапсуляции. В мире людей опытных, которые не зашорены как вы, и помнят языки чисто процедурные, давно ведутся дебаты по поводу того, что MVC - вообще BAD DESIGN.
Во-вторых, MVC != фреймворк, это ПАТТЕРН Model-View-Controller. Паттерн! Архитектурный паттерн. Один из многих, и не обязательно единственный и истинный. Это разделение бизнес-логики и ее отображения, не более.
В третьих, фреймворки написаны бывают не только реализуя MVC-паттерн. И не только ООП-фреймворки. Процедурное программирование было, есть и будет. У ООП свои плюсы и минусы, у Procedural свои. Это не лучше/хуже, это разные подходы.
Так, чтобы вы понимали, WordPress изначально написан на фреймворке. Процедурном, реализующем EVENT-DRIVEN паттерн. Учите матчасть.
А еще в WordPress дохрена ООП (и постепенно его становится все больше, не так быстро как хотелось бы - в силу огромной важности backward compatibility, но все же) и сам по себе WP - это Content Management Framework с кучей встроенных API, как и у любого фреймворка. А сверху накинута отличная админка. По сути, единственный ваш concern, это шаблонизатор WP, который для адептов MVC выглядит странным и олдскульным. Впрочем, это вопрос привычки, немного идеологии. К реальным задачам и их реализации он никакого отношения не имеет.
> в Wordpress очень мало архитектурных слоев
шта? Проясните, что вы имеете в виду.
ЗЫ: Термин "Монолитная CMS" не гуглится и мир о нем ничего не знает. Что опять же свидетельствует о том, что у вас каша в голове, смешались кони-люди, и вы плохо отличаете теплое от мягкого.
ЗЗЫ: Про стаж я написал как контраргумент к вашему опрометчивому заявлению, что кроме WP я ничего не знаю и не видел.
Ferragut: Если вы используете HTTP/1.1, то на выходе делайте минификацию скриптов и стилей + конкатенацию в один файл. Впрочем, на стороне WP это делается с помощью плагинов, которые собирает все вместе, поэтому не обязательно делать это галпом. Если используете HTTP/2 то это не нужно вообще. Ну ок, минификация еще возможно (надо тестить), а вот конкатенация не только не нужна.
АртемЪ: таблица wp_postmeta содержит почти 12 млн строк. Товаров под 200к. Терминов правда меньше, но это как раз не столь важно. Нагрузка высокая (северная Америка, популярный магазин), в распродажи - адская. Ситуация с запросами по postmeta путем перебора всех строк это конечно тормоза, в силу архитектуры данной таблицы. Решается на ура с помощью Elastic Search, который ищет мгновенно и возвращает ID конкретных товаров которые надо отобразить базовым WP_Query без какого-либо перебора метаданных.
я лично знаю и принимал участие в разработке магазинов на WP+WC, в которых объем данных превышал озвученный раз в 5. И все прекрасно работает. Не уметее готовить - не беритесь и не говорите другим ерунды.
Влад Серов: Все правильно. Потому что на ссылках вызывается javascript, но он не работает корректно, в консоли должна быть ошибка, которая объяснит почему, что именно не так. Скорее всего не видит $
Влад Серов: значит не отрабатывает скрипт. Первое - смотрим зависимости. Ему нужен jQuery? Убедитесь что он подключен. И даже если он подключен, будет второй нюанс - jQuery в WP работает в режиме noConflict. Если ваш скрипт использует $ - работать не будет. Смотрите консоль на предмет ошибок. В общем, как я и писал, все скрипты надо подключать через wp_enqueue_scripts, jQuery указывать как dependency, а сам код js писать с учетом режима noConflict. Все это описано в документации по ссылке.
Rou1997: а с чего вы взяли, что я только с WP знаком? :) Я с 1997 года колбашу, до PHP был Perl еще, а с ООП знаком из других языков задолго до того, как WP появился на свет. Мой сознательный выбор в пользу WP в последние годы - совершенно другой вопрос. Не пишите ерунды, у вас кони-люди смешались.
