MainWP Bulk Settings Manager - Плагин WordPress

Руководство по настройке MainWP Bulk Settings Manager для массового управления настройками WordPress

MainWP Bulk Settings Manager нужен не для обычных обновлений плагинов и тем, а для более тонкой задачи: один раз подготовить нужные настройки на эталонном сайте, превратить отправленную форму в ключ и применить этот ключ к выбранным дочерним сайтам из MainWP Dashboard. В этом руководстве разберём, когда такой подход действительно экономит время, как безопасно создать ключ через MainWP Key Maker, как проверить поля перед отправкой и почему некоторые формы лучше не трогать массово.

Материал рассчитан на владельца сети сайтов, веб-студию или специалиста по поддержке, который уже понимает базовую логику MainWP: есть отдельный сайт Dashboard, есть дочерние сайты с MainWP Child, а управление выполняется из центральной админ-панели. Здесь не будет повторного рекламного описания продукта. Вместо этого будет практическая инструкция: подготовка, установка, создание Single Key, работа с Key Ring, применение Boilerplate tokens, реальный сценарий с настройками WordPress, проверка результата и диагностика ошибок.

Главная мысль простая: Bulk Settings Manager не угадывает смысл настроек, он повторяет данные отправленной формы. Поэтому качество результата зависит от того, насколько аккуратно выбран эталонный сайт, какая форма была отправлена, есть ли уникальные поля вроде URL и адреса почты, и проверили ли вы значения перед отправкой на группу сайтов.

Какую задачу решает расширение и где оно особенно полезно

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

Пример из практики: у агентства есть группа небольших клиентских сайтов с одинаковым SEO-плагином. На каждом нужно включить один набор общих параметров, поменять поведение ссылок, обновить настройки хлебных крошек или привести общую страницу настроек к единому стандарту. Без Bulk Settings Manager специалист открывает каждый сайт, переходит в нужный раздел, повторяет одни и те же клики, рискует ошибиться на одном из сайтов и тратит время на сравнение. С расширением сначала на одном эталонном сайте настраивается форма, затем MainWP Key Maker считывает отправленный запрос, а Bulk Settings Manager импортирует этот запрос как ключ.

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

У продукта есть три сильных сценария:

• Повторение настроек WordPress Core, например общих параметров, обсуждений, медиа или других стандартных форм, если значения должны совпадать на выбранной группе сайтов.
• Перенос конфигурации плагина, когда один плагин установлен на многих дочерних сайтах и его форма настроек сохраняется обычной отправкой.
• Передача настроек темы, если тема имеет форму параметров, которую можно захватить через MainWP Key Maker и затем применить через Dashboard.

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

Кому подойдёт MainWP Bulk Settings Manager, а кому лучше выбрать другой инструмент

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

Особенно удачный профиль пользователя - человек, который уже ведёт список групп сайтов в MainWP, понимает различия между Dashboard site и Child site, делает резервные копии перед массовыми изменениями и не отправляет изменения "на все сайты" без проверки. Bulk Settings Manager усиливает такую дисциплину: он ускоряет повторяемые действия, но не отменяет необходимость думать о последствиях.

Когда расширение будет удачным выбором

Используйте MainWP Bulk Settings Manager, если у вас есть повторяемая настройка, понятная группа дочерних сайтов и эталонный сайт, где нужное состояние уже проверено. Хорошие кандидаты - одинаковые настройки SEO-плагина на сайтах одной ниши, общие параметры комментариев, единая конфигурация темы для сети лендингов, настройка плагина безопасности после уже пройденного подключения к внешнему сервису.

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

Когда лучше не использовать массовый ключ

Расширение может быть неподходящим, если каждый сайт имеет уникальную конфигурацию или если форма содержит критичные уникальные поля. Например, на странице Settings - General нельзя бездумно копировать URL сайта и адрес WordPress на все дочерние сайты. Для таких полей в документации MainWP предлагается использовать Boilerplate tokens, но это требует отдельной подготовки.

Не стоит применять Bulk Settings Manager к формам, где сохранение зависит от внешней авторизации, одноразового токена, мастера подключения или нестандартной логики. Документация приводит пример с этапом первичной проверки учётных данных Jetpack: до завершения внешней проверки ключ может быть неполным или бесполезным. Похожая осторожность нужна для плагинов, где включение модуля происходит не через обычную отправку формы.

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

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

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

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

Мини-чеклист перед началом

• Убедитесь, что MainWP Dashboard работает на отдельной или хотя бы не перегруженной установке WordPress.
• Проверьте, что нужные дочерние сайты подключены, синхронизируются и доступны из Dashboard.
• Проверьте, что на эталонном сайте установлен тот же плагин или та же тема, что и на целевых сайтах.
• Сделайте резервные копии сайтов или хотя бы тех сайтов, где настройки критичны для заказов, форм, SEO и авторизации.
• Определите небольшую тестовую группу: один или два сайта, на которых можно безопасно проверить первый ключ.
• Выпишите поля, которые не должны стать одинаковыми на всех сайтах: URL, название сайта, адрес администратора, токены, API-ключи, локальные ID, email-адреса клиентов.

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

Почему эталонный сайт должен быть чистым

Эталонный сайт - источник будущего ключа. Если на нём включены временные параметры, тестовые адреса, локальные пути или экспериментальные настройки, Bulk Settings Manager добросовестно перенесёт именно их. Поэтому перед захватом формы стоит открыть нужный раздел, привести значения к финальному состоянию, сохранить форму и только после этого нажимать кнопку MainWP Key Maker.

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

Установка расширения и MainWP Key Maker без лишнего риска

Bulk Settings Manager устанавливается на сайт MainWP Dashboard как MainWP Add-on. Не устанавливайте это расширение на дочерние сайты: дочерним сайтам нужен MainWP Child, а для создания ключа на эталонном сайте временно используется MainWP Key Maker. Документация MainWP по управлению Add-ons отдельно разделяет расширения Dashboard и обычные плагины WordPress.org, и это разделение здесь важно.

Общий путь установки выглядит так: в MainWP Dashboard откройте раздел управления Add-ons, найдите Bulk Settings Manager, установите и активируйте его. Если используете ручную установку через ZIP, загружайте архив только в админке Dashboard-сайта. После активации расширение появляется в группе административных Add-ons и получает собственные вкладки для импорта, Single Keys, Key Rings и настроек.

Где используется MainWP Key Maker

MainWP Key Maker - бесплатный плагин из каталога WordPress.org. Его задача узкая: на сайте, где уже настроена нужная форма, он считывает данные отправленного запроса и показывает ключ, который можно импортировать в Bulk Settings Manager. В описании плагина прямо указано, что он полезен только вместе с MainWP и Bulk Settings Manager.

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

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

После активации Bulk Settings Manager откройте его страницу в MainWP Dashboard и проверьте три вещи. Во-первых, доступны ли вкладки импорта и списка ключей. Во-вторых, видна ли настройка задержки между отправками. В-третьих, есть ли опция Use Boilerplate, если вы планируете использовать токены из MainWP Boilerplate. Если Boilerplate не установлен и не активирован на Dashboard, токены не будут заменяться как нужно.

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

Механика ключей: Single Key, Key Ring и задержка между отправками

Чтобы пользоваться расширением уверенно, нужно понимать три понятия. Single Key - один набор данных отправленной формы. Key Ring - группа ключей, которую можно применить вместе. Delay - задержка между отправками на дочерние сайты, чтобы снизить нагрузку на сервер и дать сайтам обработать изменения по очереди.

Single Key: когда достаточно одного ключа

Single Key подходит, если нужные настройки находятся в одной форме. Например, вы хотите применить один набор параметров обсуждений WordPress или одну страницу настроек SEO-плагина. В таком случае создаётся один ключ, он проверяется на экране Edit Key, сохраняется и отправляется на выбранные дочерние сайты.

На экране редактирования ключа не стоит просто нажимать Save Key по привычке. Раскройте поля, посмотрите имена и значения, сравните их с целью. Если видите непонятные токены, пустые значения, URL конкретного сайта или email клиента, остановитесь и разберитесь, должно ли это поле переноситься.

Key Ring: когда у плагина несколько форм

Многие плагины делят настройки на вкладки или мини-формы. Документация MainWP отмечает, что Key Maker может показывать несколько post-submission requests, если на странице несколько мини-форм. В такой ситуации один ключ может захватить только часть настроек, а для полного сценария нужны несколько ключей.

Key Ring решает именно эту задачу: вы создаёте несколько Single Keys, затем объединяете их в один набор и отправляете вместе. Например, для плагина может быть отдельный ключ для общих параметров, отдельный для поведения ссылок и отдельный для уведомлений. Key Ring помогает не забыть один из связанных ключей и применить их как единый рабочий пакет.

Delay: зачем нужна пауза

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

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

Как создать ключ через MainWP Key Maker и не захватить лишние поля

Создание ключа начинается не в MainWP Dashboard, а на эталонном сайте. Откройте сайт, где нужный плагин или тема уже настроены правильно, перейдите на нужную страницу параметров, проверьте значения и отправьте форму штатной кнопкой сохранения. Это нужно потому, что Key Maker рекомендует использовать post-submission request - данные после реальной отправки формы.

Документация MainWP отдельно предупреждает, что pre-submission requests часто дают неполные ключи. На практике это означает: если вы возьмёте данные до отправки формы, часть полей может не попасть в ключ, а на дочерних сайтах результат будет неполным. Поэтому рабочая последовательность такая: сначала сохранить форму, затем открыть MainWP Key Maker, затем выбрать post-submission request.

Пошаговый процесс создания ключа

1. На эталонном сайте откройте страницу настроек, которую хотите повторить на дочерних сайтах.
2. Выставьте нужные значения и нажмите штатную кнопку сохранения формы.
3. Нажмите кнопку MainWP Key Maker в верхнем меню WordPress.
4. Выберите post-submission request, а не pre-submission request.
5. Откройте проверку полей и значений, чтобы увидеть данные в читаемом виде.
6. Если форма разбита на несколько запросов, выберите самый полный запрос с нужными полями.
7. Скопируйте код ключа в буфер обмена.
8. Вернитесь в MainWP Dashboard и откройте Bulk Settings Manager.
9. На вкладке Import Keys вставьте код, задайте понятное имя и импортируйте ключ.
10. После перехода на Edit Key проверьте поля, при необходимости измените значения и сохраните ключ.

Имя ключа должно быть понятным через месяц, а не только сегодня. Плохое имя - "SEO". Лучше: "Rank Math General Settings - базовый профиль агентства" или "WordPress Discussion - комментарии закрыты для лендингов". Для Key Ring используйте ещё более ясное имя, например "SEO базовый пакет - общие, breadcrumbs, sitemap".

Как понять, что ключ полный

Полный ключ содержит поля, которые вы ожидаете увидеть по форме. Если на странице настроек было десять важных параметров, а в проверке видны только два скрытых поля и nonce, такой ключ нельзя применять. Вернитесь на страницу, ещё раз сохраните форму, проверьте другой post-submission request или посмотрите, не сохраняет ли плагин часть настроек отдельными мини-формами.

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

Настройка после установки: Delay, History и Use Boilerplate

Раздел настроек Bulk Settings Manager небольшой, но именно он определяет безопасность массовой отправки. В официальной документации перечислены три ключевых элемента: Delay, Clear History и Use Boilerplate. Их нельзя воспринимать как второстепенные переключатели.

Delay как настройка нагрузки

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

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

Clear History и дисциплина журнала

История помогает понять, какие ключи уже отправлялись и когда. Кнопка Clear History удаляет исторические данные расширения. Используйте её не как "почистить всё после работы", а как административное действие. Если вы ведёте поддержку клиентов, история может помочь восстановить цепочку изменений.

Перед очисткой истории стоит убедиться, что у вас есть другой журнал: внутренний тикет, заметка в CRM, описание в changelog проекта или хотя бы сохранённая таблица "какой ключ применён к какой группе". Bulk Settings Manager ускоряет действия, но журнал ответственности всё равно остаётся на администраторе.

Use Boilerplate для уникальных значений

Use Boilerplate включает замену Boilerplate tokens в значениях ключа. Это нужно, когда часть формы должна быть общей, а часть - уникальной для каждого сайта. Самый понятный пример - страница общих настроек WordPress, где siteurl и home не должны стать одинаковыми на всех сайтах.

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

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

Практический сценарий: меняем административный email на группе дочерних сайтов

Официальная документация MainWP разбирает сценарий изменения WordPress Administration Email Address через Bulk Settings Manager и Boilerplate. Он хорошо показывает главную логику продукта: форма общих настроек WordPress содержит и общие значения, и уникальные значения, поэтому применять её напрямую опасно.

Цель сценария: заменить административный email на выбранной группе дочерних сайтов, не сломав уникальные адреса сайта. Подготовка: Bulk Settings Manager и Boilerplate активны на Dashboard, MainWP Key Maker установлен на эталонном дочернем сайте, для каждого целевого сайта в Boilerplate заполнены значения URL-токенов.

Шаги сценария

1. На Dashboard включите Use Boilerplate в настройках Bulk Settings Manager.
2. На эталонном сайте с Key Maker откройте Settings - General.
3. Укажите нужный административный email и сохраните форму.
4. Через MainWP Key Maker выберите post-submission request и скопируйте ключ.
5. В Bulk Settings Manager импортируйте ключ через Import Keys.
6. На экране Edit Key найдите поля URL, которые не должны быть одинаковыми.
7. Замените URL-значения на Boilerplate tokens, соответствующие каждому дочернему сайту.
8. Найдите поле административного email и проверьте новое значение.
9. Сохраните ключ и отправьте его сначала на один тестовый сайт.
10. После проверки примените ключ к остальным выбранным сайтам.

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

После отправки ключа откройте тестовый дочерний сайт и проверьте страницу Settings - General. Административный email должен измениться на нужный, а WordPress Address и Site Address должны остаться корректными для этого сайта. Если URL стали одинаковыми с эталонным сайтом, немедленно откатите через новый исправляющий ключ или вручную восстановите значения.

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

Нюанс сценария

Этот сценарий выглядит простым, но он опасен именно из-за смешения общих и уникальных полей. Если ваша цель - изменить только email, а остальная форма содержит десятки параметров, подумайте, действительно ли стоит использовать всю форму. Bulk Settings Manager отправляет значения ключа, а не "только смысловое изменение email". Поэтому перед сохранением ключа удаление или корректировка лишних полей может быть важнее самой отправки.

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

Отправка ключа - самый короткий этап в интерфейсе, но не самый простой с точки зрения ответственности. В Bulk Settings Manager вы открываете Single Keys или Key Rings, выбираете ключ, выбираете дочерние сайты и нажимаете Save Key или Save Key Ring. На этом этапе важно не перепутать группу сайтов и не отправить ключ шире, чем планировалось.

Используйте группы и теги MainWP осознанно. Если у вас есть сайты на разных стеках плагинов, не отправляйте один ключ по всей сети. Лучше создать группу "лендинги на одном шаблоне", "магазины с одинаковым SEO-профилем", "тестовые сайты", "клиентские сайты без уникальных настроек". Тогда выбор сайтов становится управляемым, а не ручным поиском по длинному списку.

Тестовая отправка

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

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

Что считать успешным результатом

Успех - это не только отсутствие красной ошибки в MainWP. Успех означает, что нужные значения сохранились на дочерних сайтах, уникальные поля не перезаписались, публичная часть сайта работает, а связанные функции не сломались. Для некоторых настроек достаточно проверки админки. Для других нужна проверка фронтальной страницы, формы, письма, sitemap, кеша или прав доступа.

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

Что Bulk Settings Manager не должен делать за вас

Главная ошибка при работе с этим расширением - ожидание, что оно анализирует форму как человек. На самом деле оно переносит поля. Если поле называется непонятно, содержит сериализованный массив или связано с внутренним ID, Bulk Settings Manager не обязан понимать, хороший это ID или нет. Поэтому сложные настройки стоит сначала проверять на тестовой группе.

Не используйте расширение как замену миграции

Bulk Settings Manager не клонирует сайт. Если вам нужно перенести весь набор страниц, медиа, таблицы, пользователей или заказы, нужен другой процесс. Здесь речь только о настройках форм. Даже если настройка визуально похожа на "экспорт конфигурации", фактически это сохранённый запрос формы, который будет повторён на других сайтах.

Не отправляйте секреты и уникальные ключи

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

Не правьте код продукта

Для Bulk Settings Manager не нужны правки ядра WordPress, файлов MainWP, дочернего плагина или целевых плагинов. Если нужная задача не решается через стандартную форму, не стоит исправлять это хаками в файлах. Для технических изменений в сети MainWP есть другие инструменты, например Code Snippets Extension, но он предназначен для опытных пользователей и требует отдельной проверки кода.

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

Ключ: [тип сайта] - [плагин или раздел] - [цель настройки]
Тест: 1 сайт из группы
Проверка: экран настроек + публичный результат
Откат: ручное восстановление или исправляющий ключ

Такой регламент проще, чем PHP-snippet, и намного полезнее для массовых настроек. Его можно применять без риска сломать сайт кодом.

Как выбирать форму для ключа и отделять безопасные поля от опасных

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

Перед созданием ключа разделите поля формы на четыре группы. Первая группа - общие безопасные значения. Это параметры, которые действительно должны совпадать на всех целевых сайтах: включённый пункт, одинаковый формат, единый режим отображения, стандартное поведение комментариев, общий флаг для SEO-плагина. Вторая группа - уникальные значения, которые можно заменить токенами: URL, название сайта, адрес организации, город, email клиента, локальные контактные данные. Третья группа - значения, которые нельзя отправлять массово без отдельной проверки: API-ключи, секреты, внутренние ID, пути к файлам, webhooks, данные внешних сервисов. Четвёртая группа - служебные поля формы, которые нужны для сохранения, но не должны становиться предметом ручного редактирования без понимания.

Безопасная форма

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

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

Форма с уникальными полями

Форма с уникальными полями не запрещена, но требует подготовки. Самый характерный случай - общие настройки WordPress. В ней рядом находятся параметры, которые можно стандартизировать, и значения, которые обязаны отличаться на каждом сайте. Документация MainWP поэтому показывает пример с Boilerplate tokens для URL-полей. Смысл токена в том, что ключ хранит не конкретное значение эталонного сайта, а заменяемый маркер, который Bulk Settings Manager подставит для каждого дочернего сайта через Boilerplate.

Перед отправкой такого ключа проверьте три вещи. Во-первых, Use Boilerplate включён в настройках Bulk Settings Manager. Во-вторых, нужный токен действительно существует в Boilerplate. В-третьих, у каждого целевого дочернего сайта заполнено значение этого токена. Если выполнить только первые два пункта и забыть третий, результат будет непредсказуемым для части сайтов.

Форма, которую лучше оставить ручной

Некоторые формы лучше не превращать в ключ. Это формы подключения к внешним сервисам, формы с одноразовыми токенами, сложные мастера начальной настройки, экраны, где параметры сохраняются отдельными асинхронными действиями, и страницы, где включение модуля не равно отправке обычной формы. Документация MainWP по примеру Rank Math осторожно отмечает, что не все страницы подходят для изменения: если модуль включается не через обычный submission request, ключ может не решить задачу.

Если форма выглядит визуально простой, но Key Maker не показывает нужных полей, это тоже сигнал остановиться. Не нужно угадывать скрытые имена полей и вручную собирать ключ, если вы не понимаете внутреннюю логику плагина. Ручной ключ допустим для продвинутых пользователей, но для обычного рабочего процесса безопаснее импортировать ключ из Key Maker и проверять поля, чем конструировать запрос "на глаз".

Мини-аудит ключа перед сохранением

После импорта ключа откройте Edit Key и задайте себе пять вопросов. Понятно ли, с какой формы снят ключ? Видны ли ожидаемые поля? Нет ли значений, которые относятся только к эталонному сайту? Не содержит ли ключ секреты или внешние токены? Можно ли проверить результат на одном сайте без долгого восстановления?

Если ответ "нет" хотя бы на один вопрос, ключ ещё не готов. Иногда достаточно переименовать его, заменить URL на Boilerplate token и удалить лишнее значение. Иногда лучше создать новый ключ из другого post-submission request. Иногда честный вывод такой: эта форма не подходит для Bulk Settings Manager, и это нормальный результат исследования, а не ошибка администратора.

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

Частые проблемы и диагностика

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

Ключ применился, но часть настроек не изменилась

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

Вероятная причина: был выбран pre-submission request, неполный post-submission request или форма разделена на несколько мини-форм. Документация MainWP прямо рекомендует проверять post-submission request и выбирать запрос, где видны нужные поля.

Что проверить: вернитесь на эталонный сайт, сохраните форму ещё раз, откройте Key Maker и используйте Verify Form Fields and Values. Если видите несколько post-submission requests, сравните их и найдите тот, где присутствует полный набор полей.

Как исправить: создайте новый ключ или несколько ключей, объедините их в Key Ring и повторите отправку сначала на тестовый сайт. Старый неполный ключ лучше переименовать или удалить, чтобы случайно не использовать его снова.

Появляется ошибка Invalid nonce

Симптом: при сохранении ключа на дочерние сайты Bulk Settings Manager сообщает об ошибке Invalid nonce.

Вероятная причина: форма использует nonce-проверку, которая мешает повторной отправке сохранённого запроса. В документации MainWP для этого случая описана опция Skip Invalid nonce в Save Key Options.

Что проверить: откройте Single Keys или Key Rings, выберите ключ и целевые сайты, найдите Save Key Options и включите Skip Invalid nonce. Если ошибка всё равно показывает конкретное действие nonce, документация предлагает добавить Text Field с указанным Name и Value mainwp-bsm-unverify-nonce.

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

На всех сайтах перезаписались уникальные URL или email

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

Вероятная причина: ключ был создан с реальными значениями эталонного сайта, а Boilerplate tokens не были применены или не были заполнены для целевых сайтов.

Что проверить: откройте Edit Key и найдите поля вроде siteurl, home, административного email, локальных путей, адресов клиентов и других уникальных значений. Проверьте, активирован ли Use Boilerplate и заполнены ли значения токенов на карточках дочерних сайтов.

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

Кнопка MainWP Key Maker не показывает нужные данные

Симптом: после сохранения формы Key Maker показывает пустой или бессмысленный набор полей.

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

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

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

Отправка на группу сайтов идёт нестабильно

Симптом: часть сайтов принимает ключ, часть отвечает ошибками или процесс занимает слишком много времени.

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

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

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

Как встроить расширение в рабочий процесс агентства

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

Начните с библиотеки ключей. Разделите их по типу: WordPress Core, SEO, безопасность, тема, служебные плагины, клиентские группы. В имени ключа указывайте назначение, а в описании - какие поля требуют проверки. Если плагин имеет несколько вкладок, создавайте Key Ring с понятным составом.

Проверочный лист перед каждой массовой отправкой

• Понятно, какую задачу решает ключ и какие поля он меняет.
• Проверено, что ключ создан из post-submission request.
• Проверены уникальные поля и Boilerplate tokens.
• Выбрана правильная группа дочерних сайтов.
• Есть резервная копия или другой способ восстановления.
• Запланирована проверка результата на админке и публичной части.

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

Где заканчивается Bulk Settings Manager и начинается другой инструмент

Если нужно развернуть одинаковый текст страницы или блоки с персональными значениями, ближе по смыслу MainWP Boilerplate. Если нужно выполнить проверочный PHP-код или вернуть информацию с сайтов, это уже зона Code Snippets Extension для опытных пользователей. Если нужно обновлять базы WooCommerce или Elementor после обновлений, есть Database Updater. Bulk Settings Manager занимает своё место между ними: повторить настройки формы там, где форма совместима и результат можно проверить.

Когда стоит использовать MainWP Bulk Settings Manager

MainWP Bulk Settings Manager будет удачным выбором, если у вас есть повторяемая настройка, стабильная сеть MainWP, понятная группа дочерних сайтов и готовность проверять результат. Это инструмент для дисциплинированного массового управления формами, а не универсальная кнопка "сделать всё одинаково".

Начните с малого: установите расширение на Dashboard, создайте один ключ через Key Maker, проверьте поля, отправьте на тестовый сайт и убедитесь, что результат совпал с ожиданием. Затем добавьте Delay, настройте Boilerplate tokens для уникальных значений и соберите Key Rings для сложных плагинов с несколькими формами.

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

Сильная сторона расширения - не только скорость. Оно помогает превратить разрозненные ручные клики в повторяемый процесс: эталонная форма, проверенный ключ, выбранные сайты, понятная проверка результата и контролируемый откат. В такой схеме MainWP Bulk Settings Manager действительно становится полезным рабочим инструментом для поддержки WordPress-сетей.