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

function ads_h2( $content ) {

	// Хорошая практика, называется "return early"
	if ( ! is_single() ) {
		return $content;
	}

	// Заготовили код рекламы
	$ad = '[AD]';

	// Инициализировали счетчик
	$count = 1; // 0 или 1, по ситуации

	// Делаем замену через коллбек
    $content = preg_replace_callback(
        '#<h2(.*?)</h2>#',
        // С помощью use передаем в замыкание дополнительные параметры
        function( $matches ) use ( &$count, $ad ) {
            // Увеличиваем счетчик
            $count++;
            // Если число четное, добавляем рекламу
            if ( $count % 2 == 0 ) {
	            return '<div class="ads_content">' . $matches[0] . $ad . '</div>';
            // Если нечетное - ничего не делаем
            } else {
                return $matches[0];
            }
        },
        $content
    );

	// Вернули измененный контент
	return $content;
}
add_filter( 'the_content', 'ads_h2' );

Бонус

Если менять цифру в if ( $count % 2 == 0 ) { вместо 2 на, скажем, 3 или 4, то реклама будет выводиться, соответственно, в каждом 3м или 4м подзаголовке.

Вы путаете теплое с мягким.

Страницы (pages) это один тип данных, он не поддерживает (по умолчанию) категории. Зато поддерживает дочерние страницы. Нужно это как раз для того, чтобы у страницы были подстраницы, с более детальным контентом, например.

Разбивка же не-иерархического контента (посты, записи, они же posts) происходит как раз с помощью таксономий (categories, tags и произвольные таксономии).

А теперь, с учетом вышеизложенного, уточните вопрос.

ЗЫ: А по поводу пропадающего фонового изображения - спросите в канале по CSS, и обязательно ссылку прикрепите. Диагностику делать без пациента - гиблое дело.

Из документации:

'number'
(int|string) Maximum number of terms to return. Accepts ''|0 (all) or any positive number. Default ''|0 (all).

То есть, вот так:

$args = array(
    ...
    'number' => 10, // нужное количество (максимальное)
    ...
);
$cats = get_categories($args);

Это что касается вашего прямого вопроса. А также, не нужно делать вот это:

$category = get_term($cat)

и вот это:

echo get_cat_name($category->term_id);

потому что функцией get_categories() вы уже получили массив объектов WP_Term, которые содержат все необходимые данные. Вот вам отрефакторенный код, который не делает ничего лишнего:

$args = array(
	'parent'         => 0,
	'hide_empty'     => 0,
	'exclude'        => array( 11, 1 ),
	'number'         => 10,
	'taxonomy'       => 'category',
	'posts_per_page' => 1,
	'pad_counts'     => true
);

$cats = get_categories( $args );

foreach( $cats as $cat ) :

	echo $cat->name;
	echo $cat->description; 

endforeach;

Ajax

Бекенд у вас весьма шустрый:



Это весьма и весьма достойный результат. С сервером и на серверной стороне все в порядке. А теперь узкие места:

1. Загрузка шрифтов с серверов Google. С вашим шустрым сервером имеет смысл шрифты стянуть себе и отдавать локально. Срежете секунды полторы:



2. Далее, есть проблема с несколькими стилями:

vcare.uz/wp-content/plugins/js_composer/assets/lib...
vcare.uz/wp-content/plugins/js_composer/assets/lib...
vcare.uz/wp-content/plugins/js_composer/assets/lib...

Они долго грузятся, можете сами в Developer Tools посмотреть. Проблема не только в том, что они долго грузятся, но и в том, что они встают в очередь так как расположены в подвале и из-за использования HTTP/1.1. Можно решить 2мя путями:

- конкатенация в один файл
- использование HTTP/2

В идеале, можно искать баланс между HTTP/2 + выборочная конкатенация.

3. Файлы

- new.vcare.uz/wp-content/uploads/2017/08/header-1.j...
- new.vcare.uz/wp-content/uploads/2017/08/bg-white22...

С ними 2 проблемы:

- грузится с поддомена (+ DNS lookup и прочие потери на новый коннект)
- динамический параметр, который предотвращает кеширование файла на стороне клиента

Перенесите файл на основной домен и уберите параметр.

4. Contact Form 7



У вас 7 (!!!) аякс-запросов этот плагин генерит. Я так понимаю, это 7 разных форм на странице. Запросы запускаются достаточно рано в цикле жизни страницы, и блокируют других ресурсов, занимая соединения с сервером. По протоколу HTTP/1.1, насколько я помню, браузер открывает до 6 соединений с сервером. В вашем случае, часть из этих 6 к моменту вызова этих ajax-запросов уже занята, и они встают в очередь друг за другом, вместе с другими ресурсами. Это умножает время ожидания. Переход на HTTP/2 заметно снизит влияние, но желательно избавиться от них вообще. Я бы советовал заменить CF7 на более адекватный плагин. Попробуйте, к примеру, Torro Forms (толковый и бесплатный, еще и с нормальным интерфейсом).

5. Еще один запрос к admin-ajax.php



Собственно, он инициирован Visual Composer'ом - это Masonry сетка. Возможно, он у меня дозапустился потому что я начал скролить страницу и докрутил до того места, где он нужен. Возможно, он не запускается по умолчанию и проблемой не является.

6. Front-end performance (парсинг и рендеринг):



Парсинг скриптов занимает много времени, ибо их много. Но от этого можно избавиться только путем уменьшения их количества, что, возможно, не вариант. А вот второй очень тревожный сигнал - это как раз время ожидания (Idle). Это как раз говорит о невозможности браузера продолжать работу на каких-то этапах из-за того, что он ждет пока прилетят запрошенные ресурсы. Переход на HTTP/2 крайне желателен + замена CF7. Это как раз тот случай, когда HTTP/2 должен дать ощутимый эффект.

Ну это так, беглый анализ. Посмотрите результаты тестирования тут: https://tools.pingdom.com/#!/2GQ2d/http://vcare.uz/

Функция the_post_tags() мне неизвестна. В коде WP такой нет. Подозреваю, вы имели в виду the_tags().

Данная функция (the_tags()) выводит список тегов, строкой. А для обработки в цикле foreach вам нужно во-первых данные получить (нужна функция которая возвращает данные а не выводит), а во-вторых возвращаемые данные должны быть массивом, а не строкой.

$tags = get_the_tags();

foreach ( $tags as $tag ) {
    if ( strpos( $tag->slug, '_en' ) !== false ) {
        echo $tag->name;
    }
}

В дополнение к Debug Bar могу посоветовать:

Query Monitor - для отладки в целом, ну и хуков тоже

WP Inspect - конкретно по хукам

То, что вы хотите, реализуется многими плагинами, поищите на wordpress.org/extend/plugins. Впрочем, если хотите пойти путем джедая, разложу по полочкам.

Пользователи сайта (сайт на WP) регистрируются.

Стандартная фича. Но если не хотите логин/регистрацию через родную форму, пишите свою. Смотрите функции register_new_user() и wp_insert_user().

Одни могут делать отзывы и подписываться на рассылку, вторые могут создавать свои странички и заполнять инфо.

Для начала, вам понадобятся разные роли. Читаем Roles and Capabilities. Можно использовать плагин для создания ролей.

Далее, если вы хотите чтобы пользователи на фронтенде сайта могли данные редактировать, вам понадобится создать страничку, скажем, "Account". Далее для нее добавьте endpoints нужных "виртуальных страничек". Вывод endpoint'ов проводите через проверку ролей и показывайте пользователю только нужные.

Вообще такой контент хранится у меня через ACF и PODS. Как сделать интерфейс управления страничками и параметрами для пользователей? Чтобы человек зашел, и мог добавить, например, свою компанию, редактировать её инфо.

А теперь для каждого созданного endpoint делаете темплейт, соответствующую форму, и обработчик этой формы. Для создания записей вам пригодятся функции wp_update_post(), update_post_meta().

И да, не забываем про проверку авторизации, ролей, редиректы где нужно, валидацию и санитизацию всех входящих данных, очистку данных на выводе и тд. В общем, стандартные моменты.

eval() не использовать. Никогда.

Подобные моменты решаются через шорткоды.

1. В functions.php

function post_tags_within_content() {
    global $post;
    $tags = get_the_tag_list( '<p>'Tags: , ', ', '</p>', $post->ID );
    return $tags;
}
add_shortcode( 'tags', 'post_tags_within_content' );

2. Использование в контенте поста:
[tags]
3. Получаемый результат:

...
<p>Tags: tag1, tag2, tag3</p>
...

при этом tag1, tag2, tag3 будут ссылками на соответствующие термины.

Параметры функции get_the_tag_list() - в документации.

2 варианта.

1. Javascript. По умолчанию визуально скрываете метабокс (CSS). При выборе чекбокса в метабоксе категорий проверяете его значение, если оно совпадает с нужным - показываете метабокс, если нет - прячете. Плюс - работает "на лету", даже с черновиками, нет необходимости сохранять запись чтобы увидеть результат.

2. PHP. Хукаетесь в do_meta_boxes, проверяете есть ли нужная вам категория у записи, если нет - делаете remove_meta_box() для вашей таксономии. Плюс - метабокс не выводится вообще, если он не нужен. Минус - записи сначала надо присвоить категорию и сохранить, чтобы метабокс появился.

Это стандартный rewrite rule для post formats. Его можно модифицировать через хук post_format_rewrite_rules. Хукаетесь в него, он принимает в виде параметра массив правил в формате "регулярное выражение" => "урл с параметрами". Далее можете циклом пройтись по ним, заменить все что надо. После этого надо пересохранить правила.