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

1. Хукаетесь в фильтр the_content
add_filter( 'the_content', 'add_class_to_list' );
2. Фильтруете контент и добавляете класс:

function add_class_to_list( $content ) {

    // тут выполняете манипуляции на $content

    return $content;
}

Есть три базовых варианта как выполнять эти "манипуляции":

2.1 Заменой подстроки
2.2 Полноценной работой с DOM
2.3 Регулярными выражениями

Далее привожу первые два варианта, по порядку:

// 2.1 - Заменой подстроки
function add_class_to_list( $content ) {

    // Находим <ul> и меняем на <ul class="list2">
    $content = str_replace( '<ul>', '<ul class="list2">', $content );

    return $content;
}
add_filter( 'the_content', 'add_class_to_list' );

// 2.2 - Работой с DOM
function add_class_to_list( $content ) {

    $doc = new DOMDocument();

    // далее все необходимые манипуляции, подробности работы с DOMDocument - в документации:
    // http://php.net/manual/en/class.domdocument.php

    return $content;
}
add_filter( 'the_content', 'add_class_to_list' );

DOMDocument полезен, когда нужно выполнять больше работы - оборачивать в дивы и тд. Регулярки бывают полезны если надо поймать вариативные данные, которые невозможно захватить с помощью str_replace.

^
(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
(\:([0-9]{1,4}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5]))?
$

Разбил группы по строчкам для удобства чтения.

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

gzip и https вместе работают без проблем, однако это открывает несколько потенциальных уязвимостей. При правильной и умелой конфигурации, с учетом этих новых векторов атаки и их mitigation по уму, использовать gzip + https можно и нужно. Но, поскольку многие пользователи дупля не отдают что они делают в своих конфигах, такое сочетание по умолчанию не рекоммендуется. почитайте, к примеру, тут.

А где ее получить надо? Если речь о странице архива данной рубрики - то get_queried_object() / get_queried_object_id().

Данный плагин, скорее всего, хукается в WooCommerce, фильтр woocommerce_product_tabs. Поэтому посмотрите где эта функция add_custom_product_tabs вызывается в add_filter. В этом вызове вы увидите приоритет и правильное обращение к самой функции (судя по коду, плагин ООП, поэтому там будет не обычная строка с именем функции). Далее с помощью remove_filter() вы его отключаете, а потом подключаете повторно, но уже с нужным вам приоритетом, примерно так:

// примерно так это может выглядеть у них в плагине:
add_filter( 'woocommerce_product_tabs', array( 'Plugin_Class', 'add_custom_product_tabs' ), 25 );

// отключаем и подключаем повторно:
remove_filter( 'woocommerce_product_tabs', array( 'Plugin_Class', 'add_custom_product_tabs' ) );
add_filter( 'woocommerce_product_tabs', array( 'Plugin_Class', 'add_custom_product_tabs' ), 140 );

Такой тазик для дизайнеров и програмеров - ни о чем. Единственное, что в нем хорошо - это логотип Apple. Можно офис фоткать и в Истаграмме хвастаться. Впрочем, понимающие все равно засмеют.

У меня MacBook Pro 15" c процессором i7 2.5Ghz, 16 гиг памяти, встроенная + дискретная видяха - вот это самое оно. И у дизайнеров, и у разрабов одновременно открыто куча всего. У дизайнеров - фотошоп, скетч, браузер, музло, документы какие-то, куча вспомогательных приложений - это как минимум. У програмеров - PhpStrom или Atom (который жрет еще больше, потому что Electron), браузер с миллионом вкладок, музло, доки, консоль, гит-клиент, клиент для БД и тд. И это я еще не упомянул Skype, Slack (которые жрут прилично) и десяток menu apps. 4 гига оперативы - это боль. Огромная такая боль. Каждый божий день. Вас люди ненавидеть начнут.

Update: по поводу разрабов, еще забыл упомянуть виртуалку (Vagrant) или другое решение для веб-сервера. Это сразу минус 1Гиг оперативы.

<?php 
if ( get_field( 'section-1_title', $page_id ) ) :

    $title = wp_title( '', false );
    echo "{$title} – {$offer1} {$offer2}";

else :

    wp_title();

endif;
?>

Хотя из вашего описания сложновато понять. Сумбурно как-то :)

Информация и комменты поступают очень скудные, но предположу, что после переноса сайта с одного сервера на другой, вам необходимо в настроках сайта в админке изменить ареса - заменить https://... на http://...

Кроме этого нужно будет пройтись по всей базе на предмет других полных URL с https. И еще в wp-config.php посмотрите, нет ли там констант FORCE_SSL.

И вот тут посмотрите, только вам все обратном порядке надо делать.

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

А вообще под каждый сайт используется отдельная база данных, отдельная установка WordPress в отдельную папку проекта в /var/www/, отдельный конфиг виртуального хоста для Apache или Nginx. Это нормально. Так сервера и работают. Так и должно быть.

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

1. Хук admin_menu срабатывает в админке (wp-admin), а не для админа. Он отвечает за сборку меню в админке.
2. Работа с ограничениями по ролям (админ, обычный пользователь и тд) идет с помощью проверок capabilities и roles.
3. Все хуки можно найти на hookr.io, в документации WordPress и, самое главное, в исходном коде как самого ядра, так и плагинов, которые вы используете.
4. Понимаете вы в целом правильно. Хуки - это контрольные точки, в которые можно подключаться и что-то делать - либо выполнять действия (action), модифицировать данные (filter). Важный нюанс - на один хук может навешиваться множество функций, каждой можно задавать свой приоритет. Также, не забывайте, что многие хуки принимают параметры. А еще фильтры, например, всегда должны возвращать данные (return $x).

Впрочем, все это есть в документации.

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

1. Использовать template_parts для уникальных частей шаблонов. Таким образом у вас будет в корне только single.php или singular.php, а уже в них можно динамически забирать post_type и в зависимости от его значения, подключать необходимый фрагмент:

get_template_part( 'my-templates-dir/single', get_post_type() ); // подключить my-theme/my-templates-dir/single-service.php, где 'service' - динамическая часть, возвращаемая функцией get_post_type()

2. Хукаться в дефолтную иерархию темплейтов и подменять пути:

function custom_template( $template ) {

	if ( is_singular( 'service' )  ) {
		return get_template_directory() . '/template/my-custom-template.php';
	}

	return $template;
}
add_filter( 'template_include', 'custom_template', 99 );