Игорь Воротнёв

Во-первых, в вашем абстрактном классе лишние точки с запятой после фигурных скобок методов.
Во-вторых, раз вы уже копипастили сюда весь код, то где у вас определяется $User?
В третьих, у меня все работает:

Сделайте себе один из лучших возможных подарков к Новому Году - выделите 1 день на то, чтобы установить и настроить Xdebug, научиться работать с ним в вашем IDE (очень рекоммендую PhpStorm), и использовать все возможности этого отладчика. Это кардинально изменит то, как вы программите.

Пожалуйста.

В принципе, у WordPress есть полезная функция wp_is_mobile(), которая возвращает булевое true/false. Она разделяет десктопы и мобильные устройства (планшеты, смартфоны). И это происходит на стороне PHP, то есть – на сервере. Впрочем, в вашем случае лучше решать с помощью CSS и media queries.

Вообще по поведению похоже на обычную работу кеша. Данные обновились, кеш инвалидируется и холодный запрос занимает 0,5с. После его выполнения результат кешируется, поэтому последующее выполнение запроса происходит "мгновенно". Грубо говоря, 0,5с - это и есть реальное время выполнения этого запроса. Вот только почему у вас нету такого с wp_postmeta - вот это уже интересно.

1. Количество записей не имеет особого значения. И 300к записей - это не много.
2. Если у вас много фильтров (а значит много метаданных и поиск надо делать по ним) - используйте ElascticSearch + ElasticPress.

Функция get_posts() является оберткой для WP_Query. Соответственно, все аргументы надо смотреть там. Аргумент 'title' должен быть строкой, а вы ему массив передаете. Поэтому он его и не понимает (и не должен). И больше одного title он тоже не поймет, ибо строка. Поэтому "элементов там может быть несколько" - не совсем понятно о чем вы и чего пытаетесь добиться.

Я так подозреваю, что $_POST['choice'] это у вас из селекта прилетает. Так вот, я б на вашем месте в value тега option в селекте этом подставлял ID записей, а не title. Тогда их множественно можно забирать.

Но из вашего описания сложно понять что именно вам надо. Отсюда - одни догадки. Опишите задачу более детально.

Я бы запилил через CLI, сам скрипт может быть и на PHP, или как расширение для WP-CLI. Им брал бы по одной записи из АПИ, записывал в WP/WC через REST API и писал подробности в лог. Отдельно написал бы простой аггрегатор / просмотрщик лога, чтобы удобно было смотреть результаты. А дальше запустил бы это все и ушел спать. В дальнейшем другой CLI-скрипт на кроне, который бы сверял данные между сторонним АПИ и WP/WC и синхронизировал данные с помощью первого скрипта.

JOIN в MySQL является синонимом INNER JOIN. А в вашем случае, если я правильно понял ваше сумбурное описание, нужен LEFT JOIN.

Впрочем, описание у вас весьма сложное для понимания, и без schema и примерных данных сложно понять все целиком.

Несколько дней назад отвечал на аналогичный вопрос.

Кратко суть:

1. Если у вас страница назначена как главная, глобальный (основной) WP_Query будет содержать данные этой страницы (это у вас сейчас).
2. Если страница не назначена, то глобальный WP_Query будет содержать последние записи (так у вас было раньше и они выводились).
3. Лечится произвольным WP_Query и циклом для вывода анонсов. По ссылке есть ссылка на документацию с примерами, также гуглите wordpress secondary loop или wordpress вторичный цикл.

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

wp-includes перезалейте

Функция the_post_thumbnail() работает только внутри WordPress Loop, потому что берет post_id (у какого поста картинку взять) из глобального $post. В вашем случаем используется обычный foreach, глобальный $post не заменяется, поэтому post_id надо передать явно через функцию верхнего уровня:

echo get_the_post_thumbnail_url( $recet['ID'], 'large', );

У вас $post_ids скорее всего содержит строку вида 1,2,3. Сделайте из нее массив:

'post__in' => explode( ',', $post_ids ),

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

Смотрите в сторону custom post types.

Если вам нужно разделить записи и новости, то я бы делал стандартные записи (posts) новостями, для этого создал страницу со слагом news, назначил ее как страницу записей, а пермалинки переименовал бы в /news/%postname%/. После этого все новости у вас станут доступны по адресу /news/слаг-конкретной-новости/, а архив всех новостей - /news/. А вот записи (если нужно их использовать для чего-то другого) надо делать как custom post type, со своей произвольной структурой. Либо наоборот, для новостей создаете custom post type, а записи оставляете для чего-то еще.