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

Если WP запускается под ajax-запрос, то в процессе устанавливается константа DOING_AJAX. Также есть функция wp_doing_ajax(), c помощью которой можно проверить - это обычный запрос или ajax. Возвращает булевое true/false.

Проверяйте, и если ajax - не меняйте значение в сессии.

Внимательно посмотрите на регулярку слева, и на маппинг справа:

(.?.+?)(?:/([0-9]+))?/?$ -> index.php?pagename=$matches[1]&page=$matches[2]

Это - основное правило (rewrite rule) для страниц WordPress. Как оно работает:

- /page-name/ - страница первого уровня
- /page-name/sub-page-name/ - страница второго уровня (дочерняя, вложенная)
- /page-name/sub-page-name/sub-sub-page-name/ - страница третьего уровня (и это не предел)

В этих случае маппинг выдаст, соответственно:

pagename=page-name
page=

pagename=page-name/sub-page-name
page=

pagename=page-name/sub-page-name/sub-sub-page-name
page=

и WP_Query будет запрашивать такие страницы. В вашем случае страница uslugi/asdfdsf, как дочерняя страницы uslugi – не существует. Отсюда и 404, все логично. Вот пример:



Если же ввести число, сработает другая часть регулярки:

- /page-name/123/

будет замаплен в:

pagename=page-name
page=123

Чувствуете разницу? Вторая переменная, $page теперь заполнилась. Это нужно для разбивки контента страницы. WordPress позволяет вам разместить на странице какой-то длинный текст/контент, и разбить его на странички. Именно эта часть регулярки отвечает за постраничный вывод.

Но поскольку в сам WP_Query отправляется запрос на получение контента страницы целиком, а постраничная разбивка происходит уже на лету, то и ответ 200 вполне логичен. Как и вывод одного и того же контента, независимо от номера страницы.

Вот пример такого запроса. Обратите внимание на установленные переменные:



Так работают стандартные rewrite rules WordPress. Что делать? Можно хукнуться в один из ранних хуков, например template_redirect, проверить контент на предмет постранички, и сделать редирект на 404. Но, зачем?

2й, необязательный параметр функции the_field() - ID объекта (записи). Если его не передавать, то функция будет использовать ID записи, которая в момент вызова находится в глобальной переменной $post. А вот там как раз в этот момент может находиться совершенно не то, что вы думаете. Отсюда и пустое значение - функция пытается взять значение этого поля у записи, у которой этого поля вообще нет. Не у той записи, которая вам нужна.

У вас вызов the_field() идет в цикле (который WordPress Loop) или нет?

Проблема с пользователями. Посмотрите тут: dustinbolton.com/wordpress-xampp-on-mac-update-per...

Во-первых, при чем здесь WordPress?
Во-вторых, если уж речь за WordPress, то он в некоторых местах свои собственные классы добавляет. Это надо учитывать.
В третьих, я бы за такие классы, которые данный пакет генерит, руки открывал.
В четвертых, а какой профит, особенно для лендинга где по умолчанию все классы будут использованы на одной и той же странице?
В пятых, с bem можно вообще не париться, это всего лишь одна из методологий / naming conventions.

Какой размер изображения выводить определяется на сервере. Это делает PHP.
Как его отображать (в оригинальном размере, уменьшить визуально, растянуть визуально, добавить рамку и отступы и тд) определяется на клиенте (в браузере) с помощью CSS.

Это разные вещи. Мухи отдельно, котлеты отдельно.

Не совсем понятно что такое циклические ссылки в данном контексте. Но в любом случае, строчка:
'walker' => new Aletheme_Nav_Walker(),
как бы явно намекает, что менюшка строится кастомным вокером. Открывайте класс Aletheme_Nav_Walker и смотрите, что там.

Ответ Александр правильно решает сам редирект. А вот как определить автоматически куда редиректить - это другой вопрос. Вставка у вас идет в контент через шорткод, значит малой кровью (разумными ресурсами) вытащить эти данные из БД не получится.

Как я бы сделал - на сохранение страницы повесил бы функцию, которая парсила бы шорткод и залинкованным записям произвольного типа дописывала бы метаданные 'linked_on_page_id'. Таким образом автоматически записи произвольного типа будут получать привязку к ID страницы, где они залинкованы. А уже в самом редиректе я бы брал это значение из метаданных и отправлял редиректом через get_permalink.

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

Админ-бар добавляется с position fixed, и переключается в position absolute при ширине менее 600px, z-index при этом равен 99999. Конфликт с вашим абсолютно спозиционированным меню неизбежен. Решение есть - WordPress в случае отображения админбара дописывает в body произвольный класс. Таргетируйте меню через этот класс и дописывайте разницу для значения top. Вот вам подробный материал на эту тему.

...
echo '<div class="col-md-4 col-sm-6 item box-hidden">
    <a href="' . get_the_permalink() . '">
        <div class="post-img">' . get_the_post_thumbnail() . '
            <div class="cat-name">' . get_the_category_list(',') . '</div>
        </div>
        <div class="post-description">
            <h3>' . get_the_title() . '</h3>
            <div class="post-meta">
                <span class="date">' . get_the_date('j F') . '</span>      
                <span class="comment-number"><i class="fa fa-comment-o" aria-hidden="true"></i> ' . get_comments_number() . '</span>
            </div>
        </div>
    </a>
</div>';
...