В общем - да. Разумеется, учетом того, что у термов нет полей content и excerpt и что тизер из description автоматом не генерируется, как это происходит с записями.
Короче, берем и программируем. Удачи!
Стоит проиндексировать поля (или комбинации полей), используемые в запросах в where и в order by. А для этого нужно видеть эти запросы. Я в аналогичной ситуации пользовался плагином Query Monitor: сидел, тыкал, смотрел, копировал в блокнотик... Потом в PhpMyAdmin, добавляя индексы, можно более-менее наглядно увидеть увеличение скорости обработка (или отсутствие увеличения, если не угадал). Можно попробовать посмотреть медленные запросы в mysql Slow log, но там не все однозначно, особенно на серверах с жесткими лимитами.
Вообще-то, проектирование БД - задача для специалиста в этой области (себя к ним не отношу ни в коей мере; так, погулять вышел).
Для начала стоит посмотреть структуру этой таблички, в частности, индексы, и какие sql-запросы на нее идут от плагина.
У WP много плагинов, которые в принципе не могут работать на больших объемах данных.
Имейте в виду, что браузеры неплохо кэшируют редиректы, и если Ваш Chrome хоть раз наскочил на редирект на другой домен, он мог это запомнить. В большинстве случаев лечится сбросом кэша браузера, но бывает так, что и это не помогает. Уж не знаю, что там за мистика, но факт остается фактом.
Могу только предположить, что get_posts (WP_Query) при создании SQL-запросов не проверяет таксономии и термы на существование/корректность, а get_terms() и/или wp_delete_term() - проверяют, скажем, с помощью функции taxonomy_exists(), которая ищет зарегистрированную таксономии в global $wp_taxonomies;
pLavrenov, использование global $product - нормальная практика WooCommerce. А передать что-то в обработчик хука (судя по всему, под функцией Вы имели в виду именно его) нет возможности, если авторы плагина об этом не позаботились. Этот хук без параметров. Используем либо глобальные переменные, либо функции.
Приличные фильтры должны модифицировать ссылки на след/пред страницы так, чтобы те открывались уже отфильтрованными. Тогда без разницы, что просто клик, что аяксная подгрузка контента. Если же ссылки не модифицируются, нужно либо менять фильтры, либо дорабатывать.
yarovikov, нетривиальные задачи, как правило, не имеют тривиальных решений. Но у правил бывают исключения. Может, кто-то знает, как по-простому решить Вашу задачу. Тем более за последние годы в mysql напихали тучу новых возможностей.
yarovikov, да, конечно. И настройка довольно заморочистая, особенно если надо подхватывать свеженькие данные в реалтайме. Зато потом поиск просто летает на больших объемах данных.
Yoast тоже не подарок. Некоторые его опции просто загоняют сайт в ступор. Впрочем, возможно, за последний год, полностью выпавший для меня, ситуация улучшилась. Хотя, учитывая общие тенденции, скорее, ухудшилась. Всё портится. Увы :(
EMarkova22, бывают. Для юникс-систем р̶а̶з̶м̶е̶р̶ регистр имеет значение. TEXT.TXT и text.txt - два разных файла. А с учетом того, что wordpress слаги и т.п. в процессе "санобработки" переводит в нижний регистр, может статься так, что из-за отличия в регистре система не найдет требуемую директорию или файл. Лучше не рисковать, мне кажется.
Да, внутри ворпресса полно файлов, имена которых начинаются с большой буквы. Но то классы, а у них и их (авто)лоадеров другие правила. Вот так и живем :)
VPN и http-proxy несколько разные вещи. У Wordpress есть встроенная поддержка прокси для исходящих запросов, выполняемых через штатный механизм WP_Http.
Если используете woocommerce, то зачем писать свою форму, фактически дублирующую уже имеющийся в плагине функционал? Или так: если все писать самому, то зачем нужен woocommerce?
В общем - да. Разумеется, учетом того, что у термов нет полей content и excerpt и что тизер из description автоматом не генерируется, как это происходит с записями.
Короче, берем и программируем. Удачи!