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

Произвожу стандартную замену названий директорий Wordpress, чтобы не было так ясно, что это Wordpress.

Прекратите фигней заниматься. Это совершенно бесполезное занятие.

отсутствует заголовок CORS «Access-Control-Allow-Origin»

Это по кросс-доменным запросам. Настраивается на уровне сервера.

Сделайте себе один из лучших возможных подарков к Новому Году - выделите 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 и синхронизировал данные с помощью первого скрипта.

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

Кратко суть:

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, а записи оставляете для чего-то еще.

Apply_filters не в хуках, это и есть хук :)

Если не вдаваться в разъяснения в виде кода (это уже хорошо сделал WP_Panda), то человеческими словами это работает так:

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

2. Чтобы дать возможность другим изменить ваше значение, вы оборачиваете его в функцию apply_filters, даете этому фильтру какое-то название (в примере панды - change_vasya_name), и передаете в эту функцию саму переменную, которая содержит ваше значение (Vasya).

3. Другой разработчик пишет свою функцию, которая подключается к этому фильтру по его имени - add_filter( 'change_vasya_name', $text ) - и эта функция на лету примет на входе то значение, которое определили вы (Vasya), может его заменить/изменить (например, на Petya) и вернуть обратно.

4. WordPress когда читает код всех файлов собирает все фильтры в одну стопочку, и их коллбеки (см. п. 3) раскладывает тоже по стопочкам, каждому фильтру свои коллбеки. На одном фильтре может быть много коллбеков (функций). Далее он сортирует их по приоритетам и выполняет по очереди. Таким образом, вместо того, чтобы просто взять ваше значение (Vasya) и использовать дальше его, WP посмотрит, есть ли на этом фильтре функции, если да - выполнит их и вместо Vasya уже будет использовать то значение, которое вернет последний фильтр (в нашем случае он один и возвращает Petya).