Как отключить бесконечный скролл в JournalX для архивов и включить обычную пагинацию

В JournalX бесконечная подгрузка удобна для ленты, но не всегда подходит для архивов, категорий и страниц с большим количеством материалов. Частый сценарий: редакция хочет стабильные URL страниц, понятную навигацию, предсказуемую индексацию и меньше нагрузки на длинных лентах. В таком случае infinite scroll лучше заменить на обычную пагинацию хотя бы в части архивов.

Ниже разберём, как понять, что именно мешает, какие варианты отключения есть в теме, и как проверить результат после изменений. Сразу оговорка: если в вашей сборке JournalX уже есть настройка для отключения бесконечного скролла, используйте её в первую очередь. Если нет — придётся править поведение темы аккуратно, без ломания шаблонов.

Когда бесконечный скролл действительно мешает

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

Типичные признаки

• в категориях и архивах нет нормальных ссылок на страницы 2, 3, 4;
• пользователь не может быстро вернуться к конкретному экрану ленты;
• аналитика хуже отражает глубину просмотра, потому что подгрузка идёт без явной смены страницы;
• поиск и индексация начинают вести себя менее предсказуемо, если контент подгружается только скриптом;
• на длинных архивах растёт нагрузка на браузер и скрипты.

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

Диагностика: где в JournalX включён infinite scroll

Прежде чем что-то отключать, проверьте, откуда именно берётся подгрузка. В JournalX это может быть:

• настройка самой темы в кастомайзере;
• опция в дочерней теме;
• скрипт, который инициализирует подгрузку на архивных страницах;
• настройка шаблона конкретного раздела.

Откройте архивную страницу и посмотрите исходный HTML, а также сетевые запросы в DevTools. Если при прокрутке появляются AJAX-запросы или запросы к отдельному endpoint'у темы, значит подгрузка работает на клиенте. Если же после перехода на следующую страницу URL меняется на /page/2/, а контент просто рендерится сервером, значит у вас уже обычная пагинация, и проблема в другом месте.

Полезно также проверить, не дублируется ли навигация. Иногда тема выводит и кнопку «Загрузить ещё», и блок пагинации одновременно. Это уже повод смотреть шаблон архива.

Пошаговое решение: отключаем бесконечный скролл и возвращаем пагинацию

Ниже — безопасный путь через дочернюю тему. Он не зависит от редактирования файлов родительской темы и проще в сопровождении.

Шаг 1. Создайте дочернюю тему или рабочий плагин для правок

Если вы правите functions.php родительской темы напрямую, изменения слетят при обновлении. Для точечной доработки лучше использовать дочернюю тему. Если у вас уже есть небольшой site-specific плагин, можно добавить код туда.

Шаг 2. Найдите и отключите инициализацию скрипта подгрузки

Если в теме есть фильтр или условие, которое позволяет отключить infinite scroll, используйте его. Названия зависят от реализации темы, поэтому здесь важно не выдумывать хуки, а искать реальные точки расширения в коде JournalX. Если такой точки нет, можно убрать скрипт на архивных страницах через wp_dequeue_script(), но только после проверки, что он действительно отвечает за подгрузку.

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( is_archive() || is_home() || is_category() || is_tag() ) {
        wp_dequeue_script( 'journalx-infinite-scroll' );
        wp_deregister_script( 'journalx-infinite-scroll' );
    }
}, 100 );

Имя хэндла journalx-infinite-scroll — пример. В реальном проекте его нужно взять из исходников темы или из списка подключённых скриптов в HTML. Если хэндл другой, подставьте фактическое имя.

Шаг 3. Подключите обычную пагинацию в шаблоне архива

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

<?php
if ( have_posts() ) :
    while ( have_posts() ) :
        the_post();
        get_template_part( 'template-parts/content', get_post_type() );
    endwhile;

    the_posts_pagination( array(
        'mid_size'  => 2,
        'prev_text' => '&larr; Назад',
        'next_text' => 'Вперёд &rarr;',
    ) );
endif;

Этот вариант работает для стандартных архивов WordPress. Если JournalX использует собственный шаблонный файл, логика остаётся той же: цикл записей плюс the_posts_pagination().

Шаг 4. Уберите конфликтующие элементы интерфейса

После отключения infinite scroll проверьте, не остались ли кнопки «Показать ещё» или индикаторы загрузки. Их нужно убрать из шаблона или скрыть только если они действительно больше не используются. Скрывать CSS-ом без отключения логики — плохая идея: скрипт продолжит работать в фоне.

Если нужен выборочный сценарий: где оставить infinite scroll, а где нет

Иногда полностью отключать подгрузку не нужно. Например, на главной ленте она уместна, а в категориях с SEO-значимым трафиком лучше оставить пагинацию. В таком случае делайте условие по типу страницы.

Если задача касается только отдельных разделов, лучше не трогать глобальное поведение темы. Проще и надёжнее отключить подгрузку на конкретных типах архивов через условные теги WordPress.

Проверка результата после внедрения

После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поведение изменилось и на фронтенде, и в HTML.

• Откройте архивную страницу в режиме инкогнито.
• Прокрутите страницу вниз и проверьте, что новые записи не подгружаются автоматически.
• Нажмите на страницу 2, 3 и убедитесь, что URL меняется на /page/2/, /page/3/.
• Проверьте, что блок пагинации виден и кликабелен на мобильных устройствах.
• Посмотрите исходный код страницы: навигация должна присутствовать в HTML, а не появляться только после выполнения JS.
• Если используете кэш-плагин, очистите кэш и проверьте страницу без старой версии скриптов.

Дополнительно откройте DevTools → Network и убедитесь, что при прокрутке не идут запросы на подгрузку следующего блока записей. Если запросы остались, значит вы отключили только интерфейс, но не сам механизм.

Частые ошибки и как их исправить

Скрыли кнопку, но не отключили скрипт

Это самая частая ошибка. Пользователь не видит кнопку, но JS продолжает грузить следующий блок. В итоге страница всё равно ведёт себя как infinite scroll, только без понятного интерфейса. Исправление: отключайте источник подгрузки, а не только визуальный элемент.

Удалили скрипт не тем хэндлом

Если wp_dequeue_script() не сработал, скорее всего, имя хэндла указано неверно. Сначала найдите реальный handle в коде темы или в списке подключённых скриптов, потом уже отключайте его.

Сломали пагинацию в кастомном шаблоне

Иногда в архиве используется нестандартный запрос через WP_Query. Тогда the_posts_pagination() может не показать страницы, если не переданы корректные параметры запроса. Проверьте, что в запросе учитываются paged и текущая страница архива.

Не учли кэш

После правок старый JS и HTML могут продолжать отдаваться из кэша. Очистите серверный кэш, кэш плагина и, если нужно, CDN. Иначе вы будете проверять не новую логику, а старую копию страницы.

Безопасность и производительность: что стоит учесть

Если вы отключаете infinite scroll ради стабильности, не забудьте про производительность. Обычная пагинация уменьшает объём данных на странице, но сама по себе не решает все проблемы. Проверьте:

• не грузятся ли лишние скрипты темы на архивных страницах;
• не выводятся ли тяжёлые блоки в каждом элементе ленты;
• не дублируются ли изображения и метаданные в шаблоне карточки;
• не создаёт ли тема лишние запросы к базе на каждой странице архива.

Если в проекте уже есть задачи по чистке дублей, отключению лишних скриптов и оптимизации архивов, имеет смысл посмотреть в сторону инструментов вроде Clearfy Pro, но только если они реально закрывают вашу задачу и не конфликтуют с JournalX. В любом случае сначала проверяйте конкретный эффект на тестовой копии сайта.

Когда лучше не править тему вручную

Если у вас нет дочерней темы, а правки нужны на боевом сайте, не вносите изменения прямо в файлы JournalX. При следующем обновлении всё потеряется. В таких случаях безопаснее:

• сделать дочернюю тему;
• вынести правки в небольшой mu-plugin или site plugin;
• проверить логику на staging;
• только потом переносить на прод.

Для JournalX это особенно важно, если у вас уже есть кастомные шаблоны архивов или дополнительные блоки в ленте. Чем меньше прямых правок в родительской теме, тем проще сопровождать сайт после обновлений.