Andrey Dontsov

"Хлебные крошки", по идее, используются как элемент навигации и как элемент семантической разметки сайта. Куда попадёт ползатель при переходе? Вот от этого и отталкивайтесь.
Криминала в любом случае нет (хотя так и не делают обычно).
Я бы, в общем, подумал, куда подклеятся запросы, связанные с услугами. Анкоры в этом плане - серьёзный инструмент, и переклеивать ключи с главной на внутреннюю будет непросто и небыстро. Возможно, ссылку на "Услуги" стоит просто повесить на 302 редирект. Ссылка есть, ничего никуда не передаёт.

С кукисами и прочим оставьте это на стандарты что уже вам даёт WP(и/или плагины что вы там используете).
После нажатия купить, у вас создаётся запись о покупке в БД, со статусом не оплачен. У покупки во всех системах для создания инет магазинов и тп уникальный айди, вот на основе его и можно генерировать уникальный (допустим
с помощью crypt) ключ идемпотентности.
После успешной оплаты в БД статус меняется на оплчен и этот заказ и его айди больше никогда не используется. Даже при повторной покупке это будет уже клон этой, но с новым айди.
Таким образом и себя защитите и в целом простое и относительно надёжное решение.
Могут быть нюансы только когда оплата прошла, а ваш сервис это узнать через обратный webhook не смогла(допустим был лаг и тп) и запись в БД не стала - оплачен. Но обычно платёжные шлюзы даёт проверять статусы оплаты и по запросу, поэтому если не приходит ответ там в течении какого-то времени, можно запрашивать в ручную. Ну и затем в любом случае устаревает запрос на оплату(почти во всех платёжках есть тайм аут на то, в какое время можно оплатить уже после создания инвойса на их стороне), так что и тут в целом все норм.

Если вы хотите программно изменить Yoast meta description и title для term, вы можете использовать функцию WPSEO_Taxonomy_Meta::set_value()1. Эта функция принимает четыре параметра: ID term, название таксономии, ключ метаданных и значение метаданных. Например:

// Изменение Yoast meta description и title для term
WPSEO_Taxonomy_Meta::set_value($term_id, 'category', 'title', 'Новый заголовок');
WPSEO_Taxonomy_Meta::set_value($term_id, 'category', 'desc', 'Новое описание');

Это должно обновить метаданные Yoast SEO для term с указанным ID.

схема

CREATE TABLE custom (
    meta_id INTEGER,
    post_id INTEGER,
    meta_key VARCHAR(32),
    meta_value VARCHAR(32)
);

INSERT INTO
    custom
VALUES
(6, 2, 'seo_descr', 'Описание стр 2');

INSERT INTO
    custom
VALUES
(7, 2, 'seo_title', 'Заголовок стр 2');

INSERT INTO
    custom
VALUES
(8, 1, 'seo_descr', 'Описание стр 1');

INSERT INTO
    custom
VALUES
(9, 1, 'seo_title', 'Заголовок стр 1');

запрос

SELECT
    DISTINCT t1.post_id AS id,
    t2.meta_value AS seo_title,
    t3.meta_value AS seo_descr
FROM
    custom t1
    LEFT JOIN custom t2 ON t1.post_id = t2.post_id
    AND t2.meta_key = 'seo_title'
    LEFT JOIN custom t3 ON t1.post_id = t3.post_id
    AND t3.meta_key = 'seo_descr'
ORDER BY
    t1.post_id;

Инструментарий не изменился (хотя и появились сложности).
Самый бюджетный - связка KeyCollector и KeyAssort (для кластеризации). КейКоллектор сейчас работает дольше и с бубном, поскольку Яндекс решил усложнить людям процессы, но пока работает.
Второй путь –использовать сервисы (например, Just-Magic, Rush Analytics и т.п.). Сильно дороже, преимуществ по качеству особых я не вижу.
Главный же вопрос: а надо ли собирать "максимально полное ядро" да ещё с опорой на ключи и их частотность?
Оптимальный вариант – собрать базовую структуру категорий по топам, и если тематика большая - масштабировать поэтапно. Раньше был смысл учитывать "хвосты", поскольку были важны вхождения. Сейчас алгоритмы-трансформеры практически эти хвосты игнорируют, им важнее интент. Да, риск создать категорию-"нулевку", не способную привлечь самостоятельный трафик из поиска остаётся. Но это не значит, что такая категория не способна получить трафик не из поиска - и этого уже достаточно, чтобы не попасть под МПК, если реальный спрос всё же есть.

Он погрузиться только в том случаи если в родительской темы он подключен через get_template_part() или locate_template()

Можно так сделать:
<body.+?((term|postid|page-id)-\d+).*?">
В группе 1 будет нужное значение.

https://regex101.com/r/CiCnnr/1

Палки не нужны

let s = "^([1-9]|[1-3][0-9]|4[0-8])$";
let isValid = new RegExp(s).test(35);

https://codepen.io/Mr_Sti4/pen/qBOLajG

Ошибка вызвана недостаточным размером бувера nginx. Это не ошибка как таковая. Она может появляться при сложных операциях, когда процессам недостаточно памяти. Посмотрите логи, если ошибка появляется редко, тогда нет смысла беспокоится, если ошибка выскакивает регулярно при выполнении какого-то очень важного и часто используемого процесса, тогда можно попробовать увеличить лимит выделяемой памяти или попытаться оптимизировать процесс.

add_query_arg().

Научитесь читать доки.

INSERT INTO wp_postmeta (POST_ID, META_KEY, META_VALUE)
SELECT * FROM (SELECT '3333', 'related_p', ' ') AS t1
WHERE NOT EXISTS (
    SELECT META_ID FROM wp_postmeta WHERE POST_ID='3333' AND META_KEY = 'related_p'
) LIMIT 1;

Как бы Вы искали "узкие места", как это дебажить, как смотреть какие именно запросы отрабатываются дольше всего?

Например, плагин Query Monitor.

Привет.

Добавить нужные размеры с помощью функции add_image_size,

add_action( 'after_setup_theme', 'wpdocs_theme_setup' );
function wpdocs_theme_setup() {
    add_image_size( 'category-thumb', 300 ); // 300 pixels wide (and unlimited height)
    add_image_size( 'homepage-thumb', 220, 180, true ); // (cropped)
}

а затем пересоздать миниатюры с помощью плагина Regenerate Thumbnails.