Crocoblock JetEngine - Плагин WordPress

Руководство по настройке и применению Crocoblock JetEngine в WordPress

Crocoblock JetEngine стоит рассматривать не как обычный набор виджетов, а как конструктор динамической структуры WordPress-сайта. В этом руководстве разберём, как спланировать данные, создать пользовательские типы записей, выбрать между CPT и CCT, настроить поля, собрать листинг, подключить запросы и проверить, что результат действительно работает на странице.

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

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

Главная идея проста: JetEngine приносит пользу тогда, когда вы сначала проектируете модель данных, а уже потом рисуете карточки и страницы. Если начать с дизайна, легко получить красивый макет, который трудно фильтровать, сортировать, переводить, переносить и поддерживать.

Что именно решает JetEngine на динамическом сайте

Базовый WordPress удобен для страниц, записей, рубрик и медиафайлов. Но как только сайт должен хранить разные сущности с собственными полями, связями и способами вывода, стандартной структуры становится мало. Например, у объекта недвижимости есть цена, площадь, адрес, галерея, агент и статус. У курса есть преподаватель, длительность, расписание и уровень. У врача есть специализация, клиника, стаж, услуги и график. Такие данные не стоит прятать в обычный текстовый редактор.

JetEngine помогает вынести такие сведения в управляемую структуру. В официальной документации плагин описывается как инструмент для работы с динамическими данными в WordPress и вывода этих данных через Elementor, Gutenberg, Bricks, Divi и Timber/Twig. На практике это означает, что вы можете создать собственный тип записей, добавить поля, построить шаблон одной карточки и затем вывести много карточек через листинг.

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

Когда нужен пользовательский тип записей

Пользовательский тип записей подходит, когда элементы должны вести себя как обычные материалы WordPress: иметь собственные URL, архивы, шаблоны, заголовки, миниатюры, авторов, SEO-поля, таксономии и публичные страницы. Это хороший вариант для каталогов, портфолио, услуг, событий, объектов, сотрудников, обзоров и других сущностей, которые должны индексироваться и открываться по отдельной ссылке.

В интерфейсе JetEngine пользовательские типы записей находятся в разделе JetEngine > Post Types. При создании вы задаёте название, слаг, подписи для админ-панели, дополнительные параметры, метаполя, административные колонки и фильтры. Не все настройки нужно менять сразу. Для первого рабочего сценария обычно достаточно уникального слага, понятных подписей, включённого заголовка, миниатюры и набора полей, которые реально будут использоваться в карточке или фильтре.

Когда лучше смотреть в сторону CCT

Custom Content Type, или CCT, нужен не каждому сайту. По документации Crocoblock, CCT хранит элементы в отдельной таблице базы данных и может быть полезен, когда данных много или когда записи не обязаны быть полноценными публичными страницами WordPress. Это подходит для внутренних заявок, больших справочников, служебных записей, отдельных наборов данных и элементов, которые выводятся через листинг, но не всегда требуют собственного URL.

У CCT есть нюанс: по умолчанию его элементы не являются обычными записями с личными страницами. Если нужен отдельный публичный экран для каждого элемента, CCT можно связать с типом записей, но это уже усложняет архитектуру. Поэтому перед выбором задайте вопрос: пользователю нужна отдельная страница каждого объекта или достаточно карточки в списке, таблице, личном кабинете либо административном сценарии?

Практическое правило: если элемент должен индексироваться, иметь понятный URL и жить как контентная страница, начинайте с CPT. Если элемент служебный, многочисленный или работает как строка данных, рассмотрите CCT, но проверьте, как именно вы будете выводить и редактировать эти элементы.

Кому подойдёт этот плагин и где он может быть лишним

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

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

Подходящие сценарии

• Каталог объектов с фильтрами, сортировкой и карточками: недвижимость, автомобили, вакансии, специалисты, учебные программы.
• Сайт услуг, где нужно связать услуги с сотрудниками, филиалами, категориями, отзывами или формами заявки.
• Контентный проект, где нужны повторяемые карточки, динамические поля, собственные таксономии и шаблоны архивов.
• Проект на Elementor, Gutenberg, Bricks или Divi, где динамический вывод должен управляться из интерфейса, а не только через PHP-шаблоны.
• Сайт с личными кабинетами, избранным, профилями, таблицами или картами, если эти функции подтверждены вашей конфигурацией JetEngine и соседними плагинами Crocoblock.

Когда инструмент может оказаться избыточным

Если вам нужно добавить одно поле "подзаголовок" к нескольким страницам, JetEngine может быть слишком большим решением. Для простых полей без сложного вывода часто достаточно ACF, Meta Box, Pods или даже небольшой разработки в дочерней теме. Если сайт полностью написан вручную и команда уверенно работает с кодом, визуальный слой JetEngine может быть менее важен, чем собственные шаблоны и контролируемые запросы.

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

Что проверить перед установкой и первым включением

Перед установкой полезно не открывать сразу список модулей, а описать будущую структуру на бумаге или в таблице. Это сэкономит больше времени, чем любая "лучшая настройка". JetEngine даёт много возможностей: пользовательские типы записей, CCT, поля, метабоксы, таксономии, отношения, запросы, листинги, динамические виджеты и блоки, REST API, таблицы, карты, календари, профили и другие модули. Если включить всё подряд, админ-панель станет шумной, а диагностика сложнее.

Мини-карта перед запуском

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

• Сущности: Какие объекты нужны сайту: специалисты, объекты, курсы, услуги, локации, события, заявки.
• Поля: Какие значения у каждого объекта повторяются: цена, город, дата, фото, статус, ссылка, рейтинг, длительность.
• Классификация: Какие таксономии нужны для группировки: категория, тип, район, направление, формат.
• Связи: Какие объекты должны быть связаны: услуга и специалист, курс и преподаватель, объект и агент.
• Вывод: Где данные появятся: карточка в сетке, отдельная страница, таблица, карта, личный кабинет, блок на главной.
• Фильтрация: По каким полям пользователь будет искать и сортировать элементы.
• Права: Кто будет добавлять и редактировать элементы: администратор, редактор, автор, пользователь через форму.

Эта карта помогает выбрать между CPT и CCT. Например, "специалисты" почти всегда лучше делать как CPT, потому что у каждого специалиста нужна публичная страница. "Заявки на подбор" могут быть CCT или форменными записями, если они не должны индексироваться и нужны только внутри админ-панели.

Совместимость с редактором и темой

Проверьте, в каком редакторе вы будете собирать шаблоны. JetEngine работает с несколькими визуальными средами, но конкретные элементы интерфейса отличаются. В Gutenberg вы будете мыслить блоками. В Elementor - виджетами и динамическими тегами. В Bricks - элементами и Query Loop. Если команда уже использует один редактор, не меняйте его только ради эксперимента, пока не собран тестовый листинг.

Также важно проверить тему. Для простого вывода карточек тема обычно не мешает, но стили, контейнеры, шаблоны архивов, ширина контента и поведение AJAX-фильтров могут влиять на результат. На копии сайта временно отключите агрессивную оптимизацию JavaScript и кеш страниц, если проверяете интерактивные фильтры или динамические запросы. После настройки включайте оптимизацию обратно постепенно.

Установка и первичная проверка в WordPress

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

1. Откройте Plugins в админ-панели WordPress и убедитесь, что JetEngine активен.
2. Перейдите в раздел JetEngine и посмотрите доступные модули. Включайте только те, которые нужны текущему сценарию.
3. Создайте тестовый тип записей или используйте существующий тип, если проверяете только листинг.
4. Добавьте два-три тестовых элемента с разными значениями полей, чтобы было что сортировать и сравнивать.
5. Создайте простой шаблон листинга и выведите его на закрытой тестовой странице.
6. Проверьте публичную часть сайта в режиме посетителя, а не только внутри редактора.

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

Какие модули включать первыми

Для каталога на CPT обычно достаточно пользовательского типа записей, метаполей, листинга и при необходимости Query Builder. CCT, REST API, карты, таблицы, профили, календарь и отношения включайте только тогда, когда они нужны конкретной задаче. Это не вопрос производительности в одном клике, а вопрос управляемости. Чем меньше лишних сущностей в проекте, тем проще поддержка.

После включения модуля сохраните настройки и обновите админ-панель. Если новый пункт не появился, проверьте роль пользователя, кеш админ-панели, конфликт с браузерным расширением и наличие других плагинов, которые меняют меню WordPress. Не меняйте сразу несколько настроек, иначе будет непонятно, что именно помогло или сломало сценарий.

Мини-итог: первый запуск считается успешным не тогда, когда плагин активирован, а когда вы создали тестовый объект, вывели его поле в листинге и увидели тот же результат на публичной странице.

Модель данных: CPT, CCT, поля и таксономии без хаоса

Самая частая ошибка при работе с динамическими сайтами - создавать поля "по ходу дизайна". Редактору захотелось подпись, дизайнеру нужна иконка, владелец попросил статус, и через месяц в проекте появляются десятки полей с похожими названиями. JetEngine позволяет быстро добавить новое поле, но это не значит, что каждое поле нужно добавлять без плана.

Как назвать поля, чтобы потом не искать ошибку

Название поля для редактора может быть человеческим: "Стоимость", "Район", "Площадь". Но техническое имя поля должно быть стабильным и понятным: price, district, area. Не используйте пробелы, кириллицу и случайные сокращения. Если поле будет участвовать в запросах, фильтрах или сортировке, его ключ должен быть предсказуемым.

Не меняйте тип поля после того, как в него уже внесены данные, без проверки последствий. Например, поле, которое раньше хранило строку, может плохо сортироваться как число. Флажки и множественный выбор могут храниться иначе, чем одиночное значение. Если фильтр не реагирует, причина часто не в дизайне карточки, а в том, что поле хранит данные не в том формате, который ожидает запрос.

Таксономия или метаполе

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

Есть промежуточные случаи. Например, "город" может быть таксономией, если городов немного и по ним нужны архивы. Но если это свободный адрес или координаты, лучше использовать поле. Правильный выбор влияет не только на админ-панель, но и на SEO, фильтры, URL и будущий импорт.

CPT и CCT в одном проекте

Иногда разумно сочетать оба подхода. Например, "Специалисты" можно хранить как CPT, потому что у каждого специалиста есть страница. "Заявки на консультацию" можно хранить отдельно, потому что это служебные данные. "Слоты расписания" могут быть отдельной сущностью, если их много и они выводятся в таблице или форме. Главное - не превращать CCT в универсальную замену всем записям. Если элемент должен вести себя как публичный материал WordPress, CPT обычно проще и понятнее.

Для CCT обязательно проверьте, нужен ли отдельный пункт меню, какие поля показывать редактору, нужно ли включать REST API endpoints и какие права доступа должны быть у пользователей. Не открывайте удалённое создание или обновление данных без понятной причины и проверки прав.

Листинги и динамические блоки: как данные становятся карточкой

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

Документация Crocoblock подчёркивает, что Listing Template определяет порядок элементов, внешний вид и набор динамических блоков. В Gutenberg для этого используются блоки вроде Dynamic Field, Dynamic Image, Dynamic Terms, Dynamic Meta, Dynamic Repeater и Dynamic Link. В Elementor и Bricks логика похожая, но названия интерфейсных элементов отличаются.

Источник листинга

При создании листинга важно выбрать правильный источник. Это могут быть записи, термины, пользователи, Query Builder, Repeater Field, REST API Endpoint или CCT. Источник нельзя выбирать наугад. Если вы хотите вывести элементы из конкретного запроса Query Builder, выбирайте Query Builder. Если нужен обычный список всех элементов CPT, можно начать с Posts. Если выводите строки CCT, выбирайте соответствующий CCT.

Ошибку источника легко спутать с ошибкой дизайна. Карточка может выглядеть пустой не потому, что сломалась верстка, а потому что динамический блок ожидает поле текущего объекта, а текущий объект относится к другому источнику. Поэтому тестируйте шаблон на простых полях: заголовок, миниатюра, одно текстовое поле, ссылка.

Динамический блок против статического блока

Внутри шаблона можно добавить обычный статический блок и динамический блок. Статический блок повторится одинаково во всех карточках. Динамический блок берёт значение из текущего элемента. Это удобно, но требует дисциплины: не вставляйте в статический блок то, что должно быть полем. Например, подпись "от 30 000" нельзя писать прямо в карточке, если у каждого объекта своя цена.

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

Маленькая CSS-правка без риска

Если карточка уже выводит правильные данные, но визуально распадается из-за разной длины описаний, можно добавить собственный класс контейнеру карточки в редакторе и аккуратно выровнять элементы через CSS. Это не правка ядра WordPress и не изменение файлов плагина. Пример ниже использует ваш класс catalog-card, который нужно назначить обёртке карточки в редакторе.

.catalog-card {
  display: flex;
  flex-direction: column;
  min-height: 100%;
}

.catalog-card .catalog-card__summary {
  min-height: 4.5em;
}

.catalog-card .catalog-card__action {
  margin-top: auto;
}

Проверка простая: откройте страницу с листингом, посмотрите карточки с коротким и длинным описанием, затем временно отключите CSS. Если сетка снова начинает прыгать, правка решает именно визуальное выравнивание. Откат - удалить класс или CSS-блок. Не используйте этот пример как универсальную магию: имена внутренних элементов задайте сами, а не привязывайтесь к случайным классам плагина.

Query Builder, отношения и фильтры: где появляется настоящая логика

Обычный листинг показывает элементы, но часто нужен не просто список, а контролируемый запрос: только опубликованные объекты, только элементы текущей категории, только связанные специалисты, только записи с определённым значением поля, сортировка по числу или вывод через REST API. Для этого используется Query Builder.

В Query Builder вы создаёте запрос, задаёте тип источника, условия, сортировку, описание и при необходимости Query ID. По официальной документации Query ID используется, в том числе, для связи с JetSmartFilters. Это поле становится критичным, когда на странице несколько листингов или несколько запросов. Если идентификаторы не совпадают, фильтр может выглядеть рабочим, но не влиять на нужный блок.

Как безопасно настроить первый запрос

Начинайте с минимального условия. Выберите тип запроса, укажите нужный post type или CCT, оставьте только опубликованные элементы и проверьте результат. Затем добавляйте сортировку. Затем - одно условие по метаполю. Затем - фильтры. Если собрать всё сразу, вы не поймёте, какая часть отвечает за пустой результат.

1. Создайте запрос в JetEngine > Query Builder и дайте ему понятное имя.
2. Выберите тип источника, например Posts Query для записей или CCT Query для Custom Content Type.
3. Укажите нужный тип записей или CCT и сохраните запрос.
4. Подключите запрос к Listing Grid через режим custom query или выберите его источником листинга, если ваш редактор это поддерживает.
5. Проверьте вывод без фильтров и дополнительных условий.
6. Добавьте Query ID только тогда, когда нужно связать запрос с конкретным фильтром или отделить его от других блоков на странице.

Отношения между сущностями

Relation Builder нужен, когда сущности связаны не как категория и запись, а как отдельные объекты. Например, специалист оказывает несколько услуг, курс ведут несколько преподавателей, объект недвижимости закреплён за агентом. JetEngine поддерживает разные типы отношений, включая один-к-одному, один-ко-многим и многие-ко-многим. Это мощная функция, но она требует аккуратной модели.

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

Макросы и динамические теги

Документация JetEngine отдельно предупреждает, что в Dynamic Visibility и custom queries Query Builder макросы нужно выбирать через кнопку Dynamic Tags, а не вводить вручную. Это важная деталь. На практике пользователь видит знакомую строку макроса, вставляет её руками и получает пустой результат. Поэтому в сложных запросах используйте генератор макросов и динамические теги, а не копирование из старой инструкции.

Если запрос зависит от текущей записи, текущего пользователя или текущего термина, проверяйте контекст. Один и тот же макрос может работать в шаблоне одной записи и не давать ожидаемого результата на обычной странице, потому что "текущий объект" там другой.

Практический пример: каталог специалистов с фильтром и карточкой

Разберём сценарий, который хорошо показывает логику JetEngine и не сводится к абстрактной демонстрации. Цель - создать каталог специалистов для сайта услуг. Посетитель должен увидеть сетку карточек, отфильтровать специалистов по направлению и открыть отдельную страницу специалиста. Редактор должен добавлять нового специалиста через понятные поля, а не через ручную верстку.

Цель и подготовка

Нам нужен пользовательский тип записей "Специалисты", таксономия "Направления", несколько полей и шаблон карточки. Для простоты не используем CCT: у каждого специалиста будет отдельная публичная страница, поэтому CPT понятнее. Перед началом убедитесь, что JetEngine активен, выбран редактор для шаблонов и есть тестовая страница, закрытая от случайных посетителей.

Шаги настройки

1. В JetEngine > Post Types создайте тип записей с понятным названием и слагом, например specialists. Включите поддержку заголовка, миниатюры и, если нужно, краткого описания.
2. Добавьте метаполя: position для должности, experience для опыта, city для города, consultation_url для ссылки на запись, short_bio для короткого описания.
3. Создайте таксономию для направлений и привяжите её к типу записей. Не делайте направление обычным текстовым полем, если по нему нужен фильтр и архив.
4. Добавьте несколько тестовых специалистов с разными направлениями, городами и изображениями.
5. Создайте Listing Template для источника Posts и выберите тип записей специалистов. В карточке выведите фото, заголовок, направление, должность, краткое описание и ссылку.
6. Разместите Listing Grid на тестовой странице. Сначала проверьте без фильтра, чтобы убедиться, что карточки видят данные.
7. Если используете JetSmartFilters, создайте фильтр по таксономии "Направления" и свяжите его с нужным Listing Grid. При нескольких листингах на странице используйте уникальный Query ID.

Ожидаемый результат

В публичной части сайта должна появиться сетка специалистов. Каждая карточка должна показывать индивидуальные значения, а не повторять один и тот же текст. При выборе направления фильтр должен обновлять нужную сетку. Ссылка в карточке должна вести на страницу специалиста или на форму записи, если такой сценарий предусмотрен.

Что может пойти не так

Если карточки пустые, проверьте источник листинга и имена полей. Если фильтр не влияет на сетку, проверьте Query ID, провайдера фильтра и то, что фильтр построен по таксономии, которая действительно привязана к типу записей. Если сортировка по опыту работает как текстовая, проверьте тип поля и тип сравнения в запросе. Если отдельная страница не открывается, обновите постоянные ссылки в Settings > Permalinks без изменения структуры и проверьте слаг CPT.

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

Как проверить результат после настройки

Проверка JetEngine-сценария должна идти по цепочке, а не по ощущениям. Недостаточно увидеть красивую карточку в редакторе. Нужно убедиться, что данные правильно сохраняются, запрос выбирает нужные элементы, шаблон выводит нужные поля, фильтры меняют именно тот листинг, а публичная страница не ломается после кеширования.

Проверка в админ-панели

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

Проверка запроса

Если используете Query Builder, сначала проверьте запрос без фильтра. Потом добавьте одно условие и снова проверьте. Не смешивайте meta query, tax query, relation query, offset, сортировку и кеширование в один непроверенный шаг. В Query Builder есть настройка кеширования запроса. В документации указано, что её можно отключить, если возникают проблемы с некорректными результатами. Это не означает, что кеш всегда плохой, но при диагностике его полезно временно исключить.

Проверка публичной страницы

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

Проверка SEO и индексации

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

Производительность, SEO и безопасность без завышенных обещаний

Динамический сайт всегда сложнее статической страницы. Каждая карточка может тянуть поля, изображения, термины, отношения и результаты запроса. Это не повод отказываться от JetEngine, но повод проектировать аккуратно. Хорошая структура данных делает сайт понятным и поддерживаемым, плохая структура делает любые фильтры и шаблоны хрупкими.

Производительность

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

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

SEO

Для публичных CPT заранее продумайте URL. Не меняйте слаг после публикации без плана редиректов. Используйте таксономии там, где нужны тематические архивы, и не создавайте пустые архивы только ради структуры. В карточках выводите полезные данные, которые посетителю действительно нужны: адрес, город, специализацию, цену, доступность, краткое описание, ссылку на подробную страницу. Не прячьте всё в изображениях и не заменяйте текст декоративными карточками.

Если проект использует Yoast SEO, Rank Math или SEOPress, проверьте совместимость и настройки вывода для пользовательских типов записей. В документации JetEngine есть отдельные материалы по SEO-интеграции, но конкретное поведение зависит от набора плагинов на сайте. Поэтому выводы о сниппетах и карте сайта нужно проверять в вашем окружении.

Безопасность и права

Не открывайте удалённые endpoints, фронтенд-редактирование и пользовательские формы без проверки прав. Если CCT или REST API используется для внешнего обмена данными, убедитесь, что доступ ограничен нужной ролью или методом авторизации. Не храните чувствительные данные в публичных полях и не выводите служебные значения в листингах.

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

Видео, которое помогает увидеть создание CPT в интерфейсе

Для визуального закрепления полезен официальный ролик Crocoblock по созданию Custom Post Type в WordPress через JetEngine. Он поддерживает intent "как создать CPT в JetEngine" и хорошо дополняет разделы про подготовку структуры, метаполя и первичную проверку. В ролике видно, где находится раздел JetEngine > Post Types, как создаётся тип записей и как добавляются тестовые данные.

Смотрите ролик не как готовую архитектуру для любого проекта, а как подтверждение интерфейсного пути. После просмотра вернитесь к собственной карте данных: какие типы записей нужны именно вашему сайту, какие поля участвуют в фильтрах и какие значения должны быть видны в карточке.

Почему листинг, фильтр или динамическое поле не работают

Проблемы JetEngine часто выглядят одинаково: пустая карточка, неработающий фильтр, неверная сортировка, исчезнувший результат, странное поведение после кеширования. Но причины обычно разные. Не начинайте с переустановки плагина. Сначала определите, на каком участке цепочки сбой: хранение данных, запрос, шаблон, фильтр, редактор, кеш или права.

Листинг пустой, хотя записи существуют

Симптом: на тестовой странице нет карточек или внутри карточек пустые поля. В редакторе может казаться, что шаблон собран правильно.

Возможная причина: выбран неверный источник листинга, запрос фильтрует не тот тип записей, поле относится к другому объекту или тестовые записи не опубликованы.

Что проверить: источник Listing Template, post type в запросе, статус записей, ключи метаполей, наличие значений в самих записях. Начните с вывода заголовка и миниатюры, затем добавляйте остальные поля.

Как исправить: выберите правильный источник, временно уберите дополнительные условия Query Builder, сохраните запрос и обновите страницу без кеша. Если после упрощения карточки появились, возвращайте условия по одному.

Фильтр отображается, но не меняет результаты

Симптом: пользователь выбирает значение фильтра, но сетка остаётся прежней или меняется не тот блок.

Возможная причина: фильтр не привязан к правильному провайдеру, Query ID не совпадает, на странице несколько листингов, дублированный блок унаследовал тот же CSS ID, используется неподходящий источник фильтра.

Что проверить: провайдера фильтра, значение Query ID в фильтре, Listing Grid и custom query, уникальность идентификатора, связь фильтра с таксономией или метаполем. Для Bricks отдельно проверьте настройки Query Loop и поле для фильтров.

Как исправить: задайте один уникальный Query ID без пробелов и спецсимволов, повторите его в нужных местах и уберите его у блоков, которые не должны фильтроваться. Если на странице один листинг и один фильтр, сначала проверьте работу без лишних ID.

Сортировка по числу работает как сортировка по тексту

Симптом: значения сортируются в странном порядке: условно 100 может оказаться рядом с 10, а не после 90.

Возможная причина: поле хранится или сравнивается как строка, а не как число. В Query Builder выбран неподходящий тип сравнения или поле заполнено с символами, которые мешают числовой сортировке.

Что проверить: тип поля, формат данных, наличие пробелов, валютных символов и единиц измерения в самом значении. Для цены лучше хранить чистое число, а валюту выводить отдельно в шаблоне.

Как исправить: приведите данные к единому формату, настройте числовой тип сравнения в запросе и проверьте сортировку на трёх-пяти тестовых элементах.

Макрос или динамический контекст ничего не возвращает

Симптом: запрос должен учитывать текущую запись, пользователя или термин, но результат пустой.

Возможная причина: макрос введён вручную там, где нужно выбрать его через Dynamic Tags, или страница не имеет того контекста, который ожидает макрос.

Что проверить: место использования макроса, текущий объект страницы, источник листинга, документацию по поддерживаемым locations. В Query Builder и Dynamic Visibility используйте динамические теги, если это требуется интерфейсом.

Как исправить: заново выберите макрос через интерфейс, проверьте fallback, протестируйте на странице, где точно есть нужный контекст, и не копируйте строку макроса из старого примера без проверки.

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

Симптом: администратор видит одно, посетитель другое; фильтр показывает старые данные; после обновления записи листинг не меняется.

Возможная причина: кеш страницы, кеш запроса, оптимизация AJAX, минификация скриптов или конфликт с кеширующим плагином.

Что проверить: страницу без кеша, временное отключение оптимизации JavaScript, настройку Cache Query в Query Builder, исключения для страниц с фильтрами и личными данными.

Как исправить: временно отключите спорную оптимизацию, очистите кеш, проверьте результат и затем возвращайте настройки по одной. Если проблема появляется только с конкретным кеширующим правилом, оставьте исключение для страницы листинга.

Когда лучше откатить настройку

Откатывайте изменение, если после него ломается базовый вывод, фильтр начинает менять не тот блок, Query Builder возвращает пустой набор без понятной причины или редакторы теряют доступ к нужной сущности. Хороший откат - не паническое удаление плагина, а возврат последнего понятного шага: отключить одно условие, убрать один Query ID, вернуть прежний тип поля, выключить один модуль или восстановить резервную копию тестовой страницы.

Когда Crocoblock JetEngine будет удачным выбором

Crocoblock JetEngine стоит использовать, если вам нужен не один дополнительный блок, а полноценная динамическая система внутри WordPress: пользовательские типы записей, поля, таксономии, связи, листинги, запросы, фильтры и проверяемый вывод на публичной странице. Он особенно полезен, когда сайт должен регулярно пополняться редакторами, а дизайн карточек и страниц должен оставаться единым.

Перед внедрением пройдите короткий путь: спланируйте сущности, создайте тестовый CPT или CCT, добавьте несколько элементов, соберите простой листинг, проверьте Query Builder, подключите фильтр только после успешного вывода и протестируйте результат без авторизации. Если эта цепочка понятна, можно переходить к расширению: отношениям, профилям, REST API, таблицам, картам или другим модулям.

Если после проверки вы видите, что продукт подходит под вашу задачу, можно загрузить Crocoblock JetEngine и протестировать его на копии сайта. Не начинайте с живого каталога и не импортируйте сотни элементов до базовой проверки. Хороший старт для JetEngine - маленький рабочий сценарий, который можно повторить, объяснить редактору и безопасно откатить.

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