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

Грубо:

function prefix_automatically_add_to_cart()
{
	// Сначала решите как будете передавать ID товара - через 
	// GET в ссылке, через кастомный rewrite, POST, куки и тд.
	// Далее, здесь получаете этот ID, в зависимости от решения выше.
	$product_id = 1;

	if ( WC()->cart->get_cart_contents_count() === 0 ) {
		// Програмно добавляем товар в корзину
		WC()->cart->add_to_cart( $product_id );

		// Переадресовываем на корзину (или чекаут)
		wp_redirect( WC()->cart->get_cart_url() );
		// wp_redirect( WC()->cart->get_checkout_url() );
		
		die;
	}
}
add_action( 'template_redirect', 'prefix_automatically_add_to_cart' );

Theme Check не говорит что тут ошибка, он как бы спрашивает WTF?! - вы декларируете поддержку Post Formats с помощью add_theme_support(), но в реальности нигде их не используете. Таким образом он вам как бы намекает - либо крестик снимите, либо трусы оденьте.

Добавьте реальные Post Formats в код темы:

- определение формата в Loop при выводе записей функциями has_post_format() и get_post_format()
- модификация вывода в зависимости от формата (или назначение кастомного CSS класса)
- добавьте CSS стили для этих кастомных классов

Либо уберите их поддержку. Потому что сейчас вы врете потенциальному пользователю/покупателю - говорите что есть поддержка, но самой поддержки на самом деле нет.

Посмотрите нет ли в консоли браузера javascript-ошибок. Если ошибки есть, то скрипты могут не работать. А разворачивается панелька скриптами.

У функций the_field() и get_field() есть второй, необязательный парамент - ID объекта, с которого брать нужное поле. Если его не указывать - берется с текущего объекта. Если нужно взять с другого - указывайте нужный ID явно. Для страниц настроек, таксономий, терминов, юзеров и тд там свой формат для этого ID. Все это есть в официальной документации плагина:

https://www.advancedcustomfields.com/resources/get... (раздел Get a value from different objects)
https://www.advancedcustomfields.com/resources/add...

Вот прямо по вашей же ссылке чуть ниже на странице есть раздел Guides, в котором есть: Deploying to Kinsta with Trellis. А если перейти по ссылке All Guides, то там еще есть: Atomic Deployment with Sage 9 and DeployBot. А вообще у них еще свой стек - Trellis. Собственно, deployment - его важная часть. В документации все детально описано.

Если же их схема вам не подходит, то деплоить можно как и любой другой проект под управлением Composer. Гуглите, тут вариантов и тонкостей вагон и тележка.

Ох, опять эта тема :)

Для начала могу сказать какой точно никогда, ни при каких обстоятельствах не использовать - W3 Total Cache. Это адище с большой буквы. Туда же все остальные плагины, которые пытаются быть "все-в-одном" и предоставлять 120 страниц конфигурации. В топку.

Далее, давайте мухи отдельно и котлеты отдельно. Есть object cache - у него свои задачи. Есть fragment cache - у него свои. Есть full page cache - это отдельная кухня. Есть кеширование на уровне сервера (nginx fastcgi_cache), все тот же full page cache но "навыворот". А еще Nginx умеет разговаривать с Memcached напрямую. И даже если сравнивать решения, которые делают одно и то же (например, тот же full page cache), разница в "эффекте" на разных серверах и даже на разных сайтах на одном сервере будет. Часто - существенная. Плюс, есть кеширование на многих уровнях на самом сервере - файловая система, кеши БД и тд. И все эти настройки будут влиять на поведение плагинов кеширования. Часто - существенно. Кеширование на стороне клиента - отдельная кухня, начиная с server push, prefetch и тд, выдача поддерживаемых форматов (brotli/gzip, woff/woff2/ttf, webp/jpg/png и тому подобное).

В общем, performance - это целый комплекс мер, решений и инструментов. Подходить к этому надо с умом и четким планом, полным пониманием всего процесса от инициации запроса клиентом и до... а нету точки Б, потому что там свои моменты.

А еще надо понимать, что ваш медленный DNS может убить всю экономию на PHP runtime. Или криво установленный SSL-сертификат. Или кеширование SSL-сессий, некорректно настроенное под специфику трафика конкретного проекта. Или канал на выходе перегруженный. Или далеко не оптимальный конфиг пула PHP. Или вообще Apache. Или I/O wait зашкаливает.

Грубо говоря, если вы надеетесь найти один волшебный плагин, который будете лепить сверху на каждый сайт и всегда получать супер-мега-быстрый сайт - вы не на то тратите свою энергию. А проводить сравнительные тесты нет смысла, потому что по сути их результаты могут иметь хоть какой-то смысл только когда вы подбираете под один конкретный сайт. Если вы проведете все те же тесты на другом сайте и на другом сервере - получите уже другие результаты.

И еще. Силы надо тратить на то, чтобы динамический сайт был быстрым. То есть, без плагинов кеширования вообще. Если сайт у вас тупит, то попытка замаскировать это сверху плагином кеширования - не самое разумное решение. Временное - да, возможно. Но не решает проблему.

В целом все ок, разница всегда будет в каких-то нюансах. В зависимости от типа проекта, нюансов будет больше или меньше. У нас плюс-минус так:

- Локальная разработка на macOS + Laravel/Valet (Nginx, PHP 7+, MariaDB, Redis/Memcached).
-Staging/production могут быть как отдельными серверами, так и находиться на одном сервере, а также могут быть много сайтов на одном сервере, или это может быть не наш сервер, а какой-нибудь Kinsta или вообще клиентская инфраструктура к которой у нас доступа нет. Поэтому devops кухня вообще отделена. С нашей стороны только автодеплой из репы через CI/CD. Ветка develop -> staging, ветка master -> production.
- WordPress, плагины, тема, и весь кастомный код являются зависимостями проекта, управляется с помощью Composer.
- Работа с функциональностью WordPress строится полностью на командной строке с помощью WP-CLI. При необходимости пишутся свои команды для него.
- Вся конфигурация проекта в .env (база, ключи, лицензии и прочее, что не попадает в git) и в папочке config в виде PHP-конфигураций (все что уже влияет на функциональность).
- Медиа-файлы на локалке либо вообще не хранятся (Valet проксирует запросы на staging/production), либо синхронизируются со staging/production. Делается это с помощью отдельного cli-скрипта, который под капотом использует rsync.
- Базы данных - отдельная история которая очень сильно зависит от специфики проекта. Где-то это простой push/pull с помощью WP Migrate DB, где-то тот же push/pull c помощью WP-CLI, где-то это целые миграции. В идеале надо стараться контент забирать с прода на стейдж и избегать публикации с dev/staging на продакшн. Но ситуации и проекты бывают разные, здесь нет одного правильного ответа.