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

Если мультиязычка зеркальная - каждая страница или статья/новость имеет перевод на другой язык, тогда один сайт и плагин для мультиязычки - WPML (платный) или Polylang (бесплатный, платные add-ons).

Если контент (структура сайта, страницы, записи и тд) на языковых версиях отличается - тогда WordPress Multisite.

Все остальное выбросьте из головы.

1. Аякс не обязателен в вашем случае.
2. Использовать совет MrTimon тем более не стоит (хотя этот метод является правильным).

В вашей ситуации наиболее простым и адекватным решением будет по старинке постить форму саму на себя (на текущий урл), хукаться в init и выполнять необходимые действия.

UPDATE: В комментариях обсуждение и детали.

У вас одинаковый slug и у post type, и у taxonomy. Соответственно, будет срабатывать первое правило из двух, а именно правило custom post type. В вашем случае, при попытке открыть урл test.com/exercises/street WP будет искать запись типа exercises (custom post type) со слагом street. Такой записи нет, отсюда 404. Термин таксономии он искать не будет, так как Rewrite API работает по принципу "нашли первое совпадение и прекратили проверку".

Хукайте в admin_post_*

Еще почитать: https://www.sitepoint.com/handling-post-requests-t...

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/