Цикл о том, что ломается, когда записи создаёт и обновляет не редактор, а программа сотнями: скорость сохранения, кэш запросов, сортировка, поля ACF, картинки и корзина — на примере обмена каталога с учётной системой, с замерами до и после.
Полный обмен каталога шёл 25 минут: на каждом сохранении тема обходила все 246 товаров ради 80 нужных. Как найти виновника по логу nginx и замеру каждого обработчика save_post и почему LIKE по сериализованной мете — только предварительный отбор.
Цикл по 82 адресатам тратил 4,69 с из 4,71 на одинаковые get_posts: запись меты и чистка кэша записи двигают метку last_changed, и все закэшированные результаты WP_Query теряются. Данные один раз до цикла — и обмен вырос с 12 до 104 товаров в минуту.
Сортировку из базы заменили сортировкой в PHP, а при одинаковом order порядок выбирает база. Запасной путь «по-старому» на втором сайте срабатывал в 10 случаях из 10 (16,83 с вместо 2,15), а прежнего порядка не было вовсе: 12 адресатов из 101 видели пару иначе. Второй ключ ID решает всё.
Снимок → старая версия → откат → новая → откат → побайтовая сверка; на рабочем сайте — то же без записи, через функцию-приёмник. Ловушка двух версий в одном процессе (7,86 против 1,6 с) и почему «страница работает» не доказывает, что данные на месте.
Импорт сливал get_field со свежими данными и писал обратно update_field: файл с выводом «URL» за два обмена превращался в 0. Сырые значения приходят с ключами полей — наивный патч перестал обновлять цены. Там же цвет массивом и фатал trim() на главной.
media_handle_sideload кладёт файл в папку по дате родителя, опечатка в ID родителя плодит бесхозные вложения, post_status any не видит корзину, восстановление из корзины держится на точном названии, а wp_update_post молча игнорирует чужие ключи. И чек-лист импорта.
$ tail -f /blog
Пишу разборы по скорости сайтов, кэшу и разработке — на живых проектах и с цифрами. Подпишитесь, и ссылка на новую статью придёт сразу после выхода. Без рекламы и спама, отписаться — в один клик.
или на почту
