MainWP Boilerplate - Плагин WordPress

Руководство по использованию и настройке MainWP Boilerplate

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

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

Главная идея расширения проста: вы пишете один исходный текст, вставляете в него placeholders - в интерфейсе MainWP они называются tokens, - а для каждого дочернего сайта задаёте свои значения. После публикации на конкретном сайте пользователь видит обычную WordPress-страницу или запись, но с локальными данными этого сайта. На практике именно вокруг токенов, выбора сайтов и повторного обновления чаще всего возникают ошибки, поэтому эти части разобраны особенно подробно.

Какую задачу решает расширение в сети дочерних сайтов

MainWP Boilerplate относится к группе content management add-ons для MainWP. Его задача - не заменить редактор WordPress и не стать универсальным конструктором страниц. Расширение закрывает более узкий, но очень частый сценарий: создать или обновить повторяющийся материал на нескольких дочерних сайтах из одного места, сохранив разные значения для каждого сайта.

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

Boilerplate решает эту задачу через центральный источник и набор токенов. В исходном тексте вы используете условные значения вроде [client.name] или собственного токена для локального телефона. На каждом дочернем сайте у токена хранится конкретное значение. При публикации или обновлении расширение подставляет нужные данные и создаёт обычную страницу или запись в WordPress. Важно думать не о копировании текста, а о контролируемой доставке проверенного шаблона.

Где плагин особенно уместен

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

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

Где MainWP Boilerplate может быть лишним

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

Практический критерий: если текст на разных сайтах совпадает на 70-90%, а отличия можно выразить токенами, MainWP Boilerplate обычно подходит. Если каждый сайт требует отдельной структуры, отдельных блоков и отдельного смысла, лучше редактировать страницы индивидуально.

Механика токенов: один шаблон, разные значения

Самая важная часть работы с MainWP Boilerplate - понять не интерфейсную кнопку, а модель данных. В шаблоне страницы хранится не финальный адрес, телефон или имя клиента, а token. Значение токена задаётся отдельно для каждого дочернего сайта. Когда расширение публикует страницу, оно берёт исходный шаблон, смотрит выбранный сайт, подставляет значения этого сайта и создаёт итоговый WordPress-контент.

Это похоже на mail merge, но для WordPress-страниц и записей внутри сети MainWP. Ошибки обычно возникают не из-за самого шаблона, а из-за пропущенного значения, неверного имени токена, использования зарезервированного токена или попытки применить один и тот же шаблон к сайтам, где нужные данные заранее не заполнены.

Стандартные и пользовательские токены

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

При создании пользовательского токена важно не воспринимать его как произвольную строку в тексте. Это будущая переменная, поэтому ей нужно короткое, понятное и устойчивое имя. Если сегодня вы назовёте токен [phone], а через месяц добавите ещё офисный, мобильный и региональный номера, шаблоны быстро станут путаться. Лучше заранее выбирать имена вроде [support.phone], [office.address], [legal.company], если такая схема понятна вашей команде.

Почему значения нужно заполнить на каждом дочернем сайте

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

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

Где токены можно использовать

Документация MainWP указывает, что токены можно использовать в заголовке и теле boilerplate-страницы или записи. Это открывает полезный сценарий: не только "одинаковая страница с разными контактами", но и разные заголовки страниц. Например, можно подготовить заголовок Support Policy for [client.site.name] и тело страницы с локальными каналами поддержки.

С пользовательскими полями нужно быть осторожнее. В support-обсуждениях встречается симптом, когда токены в custom fields ведут себя не так, как ожидает пользователь при публикации на несколько сайтов. Поэтому для первого внедрения лучше держать критичные данные в заголовке и теле страницы, а custom fields проверять отдельно на небольшом наборе сайтов. Если ваш рабочий процесс зависит от произвольных полей, обязательно сделайте тест на двух-трёх дочерних сайтах с разными значениями токена.

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

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

Проверьте основу MainWP

Расширение устанавливается на MainWP Dashboard, а не на дочерние сайты. Перед началом убедитесь, что Dashboard установлен на отдельном WordPress-сайте, child sites подключены, синхронизация проходит без ошибок, а у администратора есть доступ к редактированию страниц и записей. Документация MainWP рекомендует держать Dashboard на чистой установке WordPress, потому что это снижает риск конфликтов с обычными публичными плагинами сайта.

Если сеть уже большая, дополнительно проверьте системные ресурсы Dashboard. Для массовых операций важны PHP memory limit, max execution time, cURL и стабильность соединения с дочерними сайтами. Boilerplate не должен становиться первым тестом вашей инфраструктуры. Сначала убедитесь, что MainWP нормально открывает список сайтов, синхронизирует данные и выполняет обычные content operations.

Соберите список страниц и токенов заранее

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

Минимальный набор для первой итерации:

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

Выберите безопасный тестовый масштаб

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

Не начинайте с 50-100 сайтов. Сначала проверьте один шаблон, разные значения токенов, обновление уже опубликованной страницы и удаление связи из Boilerplate. Только после этого расширяйте группу.

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

MainWP add-ons устанавливаются на сайт Dashboard. В документации MainWP описано несколько вариантов установки: через MainWP > Add-ons > Manage Add-ons, через загрузку ZIP в стандартном установщике WordPress или вручную в папку wp-content/plugins. Для большинства администраторов самый понятный путь - встроенный менеджер add-ons в Dashboard.

Где устанавливать MainWP Boilerplate

Устанавливайте расширение только на Dashboard site. На дочерние сайты ставится MainWP Child, а не Boilerplate. Это частая логическая ошибка у новых пользователей MainWP: они пытаются установить каждое расширение на каждый проект. В нормальном сценарии Boilerplate живёт в центральной админке и через MainWP выполняет действия на выбранных дочерних сайтах.

1. Откройте MainWP Dashboard под администратором.
2. Перейдите в MainWP > Add-ons > Manage Add-ons.
3. Найдите MainWP Boilerplate в списке расширений или через поиск add-ons.
4. Установите и активируйте расширение штатным способом.
5. После активации проверьте, что раздел Boilerplate появился в меню расширений MainWP.

Если вы ставите ZIP через WordPress, путь похож на обычную установку плагина: WP Admin > Plugins > Add New > Upload Plugin. Но результат должен быть тем же: расширение активно именно на Dashboard.

Что проверить сразу после активации

После установки не переходите сразу к массовой публикации. Сначала откройте раздел MainWP > Extensions > Boilerplate и убедитесь, что доступны вкладки для Boilerplate Pages, Boilerplate Posts и Custom Tokens. На странице токенов должны быть видны доступные token-элементы и их описания. Если в интерфейсе отсутствуют кнопки создания токена или boilerplate-материала, проверьте обновления расширения и MainWP Dashboard, потому что в changelog у MainWP отдельно упоминались исправления таких элементов интерфейса.

Затем откройте карточку одного дочернего сайта через MainWP > Sites > Manage, выберите действие редактирования и найдите блок Boilerplate Settings. Именно там задаются значения токенов для конкретного сайта. Если блок не найден, проверьте, активировано ли расширение, доступен ли нужный раздел в интерфейсе и не скрывает ли его роль пользователя или конфликт админки.

Настройка токенов: как не сломать массовую публикацию

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

Создание пользовательского токена

Для пользовательского токена откройте MainWP > Extensions > Boilerplate > Custom Tokens и используйте кнопку создания нового token. В форме задаются имя и описание. Скобки вокруг имени вручную добавлять не нужно, потому что расширение добавляет их автоматически. Описание стоит заполнять так, чтобы другой редактор понял назначение токена без устного объяснения.

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

Заполнение значений для дочерних сайтов

После создания токена он должен появиться в Boilerplate Settings на странице редактирования дочернего сайта. Для каждого сайта задайте конкретное значение и сохраните карточку сайта через Update Site. Повторите действие для всей тестовой группы. Не полагайтесь на память: отмечайте заполненные сайты в рабочей таблице.

Если токен относится к клиентским данным, полезно разделить ответственность. Администратор MainWP создаёт token и технически заполняет значения, а менеджер клиента или редактор подтверждает корректность адресов, названий и юридических формулировок. Boilerplate ускоряет доставку контента, но не проверяет юридическую точность текста за вас. Это особенно важно для страниц с юридическими и клиентскими обязательствами.

Настройки, которые лучше не трогать без причины

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

Не используйте зарезервированные токены, которые MainWP связывает с клиентскими или отчётными функциями, если вы не уверены в их назначении. В документации Boilerplate отдельно приведён список token-имен, которых нужно избегать при создании собственных полей. Это не косметическое ограничение: совпадение имён может привести к путанице между Boilerplate, client tokens и reporting tokens.

Таблица безопасной подготовки токенов

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

Создание boilerplate-страницы или записи

После подготовки токенов можно создавать исходный материал. В MainWP для этого предусмотрены отдельные пути: для страниц используется MainWP > Pages > Add Boilerplate, для записей - MainWP > Posts > Add Boilerplate. По логике это похоже на создание обычной WordPress-страницы или записи, но с важным отличием: вы выбираете дочерние сайты и вставляете токены в исходный текст.

Страница или запись: как выбрать формат

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

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

Как вставлять токены в материал

Токены можно набрать вручную или вставить через tokens meta box в редакторе Boilerplate. Второй способ безопаснее для новичка, потому что снижает риск опечатки. Если token написан неверно, расширение не сможет подставить значение. После вставки внимательно проверьте заголовок и тело материала. Особенно легко ошибиться в похожих токенах: [client.name], [client.site.name], [client.email] и собственных полях.

<h2>Support Policy for [client.site.name]</h2>
<p>For urgent support, contact us at [support.email].</p>
<p>Office address: [office.address].</p>

Такой пример не является обязательным шаблоном для копирования. Он показывает принцип: в исходном тексте остаются token-места, а конечные значения появляются только после публикации на выбранном сайте.

Выбор дочерних сайтов и первый publish

Перед нажатием Publish проверьте список выбранных сайтов. Для первого запуска используйте тестовую группу. После публикации откройте созданную страницу на каждом выбранном child site. В документации MainWP указано, что после создания boilerplate-страница выглядит как обычная WordPress page и видна в WP > Pages > All Pages на дочернем сайте. Это удобно для проверки: вы можете открыть страницу как посетитель и как администратор WordPress.

Редактирование, добавление нового сайта и удаление связи

Созданные Boilerplate Pages и Posts сохраняются на стороне MainWP Dashboard и остаются редактируемыми. Если нужно изменить общий текст, откройте соответствующую вкладку в MainWP > Extensions > Boilerplate, выберите материал и внесите правку. После Update изменения применяются к выбранным дочерним сайтам.

Если к сети добавился новый child site, не создавайте отдельную копию страницы вручную. Откройте существующий boilerplate-материал, найдите блок выбора сайтов, добавьте новый сайт и обновите материал. Так новый сайт получит тот же шаблон с собственными token values.

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

Практический сценарий: единая страница поддержки для клиентов

Разберём реалистичный сценарий для агентства, которое обслуживает несколько клиентских сайтов. Нужно создать страницу поддержки на каждом сайте: структура одинакова, но отличаются название сайта, email поддержки, телефон, URL формы и время ответа. Такой сценарий хорошо показывает, как пользоваться MainWP Boilerplate без абстрактных примеров.

Цель

Получить страницу Support Policy на выбранных дочерних сайтах. На каждом сайте посетитель видит свои контактные данные и корректное название проекта. Администратор агентства может позже обновить общий текст политики из MainWP Dashboard, не входя в каждый WordPress отдельно.

Подготовка

Перед созданием страницы подготовьте четыре пользовательских токена: [support.email], [support.phone], [support.form], [response.time]. Заполните значения для двух тестовых сайтов и проверьте, что данные отличаются. Если на обоих сайтах значения одинаковые, вы не увидите главную проверку подстановки.

Шаги

1. Откройте MainWP > Extensions > Boilerplate > Custom Tokens и создайте недостающие токены с понятными описаниями.
2. Откройте карточки тестовых child sites через MainWP > Sites > Manage и заполните Boilerplate Settings для каждого токена.
3. Перейдите в MainWP > Pages > Add Boilerplate.
4. Создайте заголовок с токеном, например Support Policy for [client.site.name], если такой token доступен в вашей настройке.
5. В тело страницы вставьте общую политику поддержки и token-места для email, телефона, формы и времени ответа.
6. Выберите только тестовые child sites и нажмите Publish.

Проверка результата

Откройте публичную страницу на каждом тестовом сайте. Проверьте, что в заголовке, email, телефоне и ссылке формы появились значения именно этого сайта. Затем зайдите в WP > Pages > All Pages на дочернем сайте и убедитесь, что страница существует как обычная WordPress page. Если тема сайта применяет собственный шаблон страницы, проверьте, что текст не обрезан, ссылки кликабельны, а стили не делают контактные данные нечитаемыми.

Нюанс, который часто пропускают

Если после публикации вы исправили значение токена на дочернем сайте, уже созданная страница не всегда меняется просто от изменения значения в настройках. Надёжный путь - открыть boilerplate-материал в MainWP Dashboard и выполнить обновление для нужных сайтов, затем снова проверить публичный результат. Так вы проверяете именно цепочку "значение токена - обновление шаблона - итоговая страница".

Идеи применения, которые раскрывают силу токенов

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

Страницы поддержки и обслуживания

Для агентства это самый понятный сценарий. Общий текст поддержки можно держать единым, а контактные каналы, SLA-формулировки и ссылку на форму обращения подставлять токенами. Если меняется общая политика, вы обновляете один boilerplate-материал. Если меняется контакт клиента, вы правите значение токена у конкретного child site и обновляете страницу.

Юридические и справочные страницы

Страницы политики конфиденциальности, условий использования и отказа от ответственности часто имеют повторяющуюся структуру. Но юридический текст нельзя генерировать без контроля. Используйте Boilerplate как механизм доставки утверждённого текста, а не как замену юридической проверки. Токенами удобно подставлять компанию, адрес, контакт для обращений и региональные детали, если они заранее проверены.

Локальные страницы филиалов

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

Внутренние инструкции для редакторов

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

Проверка результата: что должно быть видно на дочернем сайте

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

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

Откройте страницу в браузере без авторизации или в приватном окне, если материал должен быть публичным. Проверьте заголовок, первые абзацы, все token-места, ссылки, контактные данные и видимость страницы в навигации, если она должна быть в меню. Если страница не добавляется в меню автоматически, это нормально: Boilerplate создаёт или обновляет контент, а меню может потребовать отдельной настройки темы или WordPress.

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

Зайдите на child site и откройте WP > Pages > All Pages или WP > Posts > All Posts. Найдите созданный материал. Убедитесь, что статус соответствует ожиданию, slug не конфликтует со старой страницей, а автор и дата публикации не мешают вашему процессу. Если на сайте уже была страница с таким же назначением, проверьте, не появились ли две конкурирующие страницы.

Проверка после повторного обновления

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

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

Если один из тестовых сайтов получил неверное значение токена, не расширяйте публикацию на всю сеть. Сначала исправьте token values, обновите только проблемный сайт и повторите проверку. Массовое исправление без понимания причины часто создаёт вторую волну ошибок.

Ограничения, SEO и безопасность контента

MainWP Boilerplate ускоряет публикацию, но не делает содержание безопасным, юридически точным или полезным для поиска автоматически. Этот раздел нужен, чтобы не применять инструмент там, где требуется другая стратегия.

Повторяющийся контент и поисковая видимость

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

Boilerplate не управляет SEO-метаданными сам по себе. Если у вас стоит SEO-плагин, метаданные, schema и индексация зависят от настроек этого плагина, темы и самого WordPress. Не обещайте клиенту, что публикация через Boilerplate улучшит позиции. Честное обещание другое: вы быстрее и аккуратнее доставите согласованный текст на нужные сайты.

Кеш, темы и конструкторы страниц

После публикации обычная WordPress-страница может проходить через кеш, шаблон темы, page builder или дополнительные фильтры контента. Если вы видите правильный текст в админ-панели, но старая версия остаётся на публичной странице, сначала очистите кеш сайта и CDN, затем проверьте шаблон страницы. Если тема скрывает контент или выводит только отдельные поля, проблема может быть не в Boilerplate, а в шаблоне вывода.

Юридические страницы и ответственность

Для privacy policy, terms of use и похожих документов используйте только утверждённые тексты. Boilerplate удобно доставляет одинаковую структуру, но не проверяет соответствие законам, отрасли, региону или реальным процессам обработки данных. Если токен подставляет email для запросов пользователей, убедитесь, что этот email действительно работает и контролируется ответственным человеком.

Почему MainWP Boilerplate может работать не так, как ожидалось

Диагностика должна идти от симптома к причине. Не начинайте с переустановки расширения. В большинстве случаев полезнее проверить token values, выбранные сайты, обновление материала, состояние MainWP Dashboard и особенности дочернего сайта.

Токен не заменился или вывел пустое место

Симптом: на дочернем сайте в тексте осталось имя токена или вместо значения появилась пустота. Возможная причина - token написан с ошибкой, значение не заполнено для этого child site, использовано зарезервированное имя или материал не был обновлён после правки значения.

Что проверить

• Откройте список Custom Tokens и сравните точное имя токена с тем, что вставлено в страницу.
• Откройте карточку проблемного child site и проверьте Boilerplate Settings.
• Сохраните карточку сайта через Update Site, затем обновите boilerplate-материал для этого сайта.
• Очистите кеш, если в админ-панели дочернего сайта текст уже правильный, а публичная страница старая.

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

На разных сайтах подставилось одно и то же значение

Симптом: страница опубликована на нескольких сайтах, но в custom field или в отдельном фрагменте появляется значение первого сайта. В support-сообществе MainWP встречался похожий вопрос про токены в custom fields. Без подтверждённого исправления для вашей конфигурации лучше не строить критичный процесс на такой схеме.

Проверьте, работает ли тот же token в заголовке и теле страницы. Если там значения корректны, а custom field ведёт себя иначе, перенесите критичный вывод в тело страницы или тестируйте отдельную публикацию по сайтам. Для сложных custom fields соберите скриншоты и системный отчёт MainWP без приватных данных и обратитесь в поддержку.

Публикация идёт медленно или падает по таймауту

Симптом: при большом количестве boilerplate-материалов и child sites обновление идёт слишком долго, Dashboard теряет синхронизацию или появляются дубли. В community-обсуждениях описывался похожий сценарий на большой сети сайтов. Это не значит, что расширение непригодно, но означает, что массовый объём нужно дробить.

Как снизить риск

• Разделите публикацию на группы сайтов вместо одного огромного запуска.
• Сначала обновляйте один boilerplate-материал, а не десятки материалов подряд.
• Проверьте серверные лимиты Dashboard: memory, execution time, cURL timeout и доступность child sites.
• Для отложенной доставки рассмотрите связку с Post Dripper, если сценарий соответствует документации.

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

Материал удалён в Boilerplate, но остался на дочернем сайте

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

Не видны кнопки создания токена или boilerplate-материала

Симптом: интерфейс открыт, но нет кнопки Create New Token или создания нового boilerplate. В changelog MainWP Boilerplate фиксировалось исправление проблемы с отсутствующими кнопками. Проверьте обновления MainWP Dashboard и расширения, права текущего пользователя и конфликты админских скриптов. Если проблема появилась после обновления, сохраните скриншот и системный отчёт для поддержки.

Страница создана, но не отображается в меню

Симптом: публичный URL работает, но в меню сайта страницы нет. Это не обязательно ошибка Boilerplate. WordPress-меню и навигационные блоки управляются темой, редактором сайта или отдельными настройками. Добавьте страницу в меню вручную на дочернем сайте или настройте общий процесс навигации другим инструментом. Boilerplate отвечает за создание и обновление контента, а не за все элементы структуры сайта.

Когда MainWP Boilerplate будет удачным выбором

MainWP Boilerplate стоит использовать, если у вас есть сеть дочерних WordPress-сайтов, повторяющиеся страницы или записи, понятный набор per-site значений и дисциплина проверки результата. Расширение особенно полезно агентствам, которые поддерживают клиентские сайты и хотят централизованно обновлять стандартные документы без ручного входа в каждый проект. Если такой повторяемости нет, инструмент лучше оставить для другой задачи.

Перед рабочим запуском пройдите короткую финальную проверку: MainWP Dashboard стабилен, child sites подключены, token values заполнены, тестовая группа опубликована, публичные страницы открываются, кеш очищен, а спорные юридические формулировки подтверждены ответственным специалистом. Если эти пункты закрыты, можно получить версию для WordPress и проверить расширение на своей тестовой группе сайтов.

Если же вам нужно импортировать много разных статей, менять настройки плагинов или строить уникальные SEO-страницы, не заставляйте Boilerplate решать чужую задачу. Используйте его там, где он действительно силён: один управляемый шаблон, разные значения на дочерних сайтах, понятная проверка результата и безопасное обновление из MainWP Dashboard.