Multisite Content Copier - Плагин WordPress

Руководство по настройке Multisite Content Copier для сети WordPress

Multisite Content Copier нужен не для обычного копирования одной страницы внутри сайта, а для более узкой задачи: перенести записи, страницы, пользователей, медиа и часть настроек из одного сайта WordPress Multisite в другие сайты той же сети. В этом руководстве разберём, как подготовить сеть, где искать настройки после установки, какие режимы выбирать для разных сценариев и как проверить, что копия не создала скрытых проблем.

Плагин относится к продуктам WPMU DEV для WordPress Multisite и особенно полезен там, где у сети есть одинаковые стартовые страницы, повторяемые новости, типовые материалы или шаблонные сайты. Но у него есть важный нюанс: это legacy-инструмент, поэтому перед применением на живой сети стоит проверять совместимость на копии или тестовом подсайте, а не запускать массовое копирование вслепую.

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

Когда копирование контента в Multisite действительно экономит время

Главный сценарий Multisite Content Copier - централизованная подготовка контента для нескольких подсайтов. В обычном WordPress можно дублировать страницу внутри одного сайта, но в Multisite каждая площадка живёт в отдельном контексте: свои записи, свои пользователи, свои вложения, свои настройки темы и плагины, если они не активированы на уровне сети. Из-за этого ручное копирование быстро превращается в цепочку мелких ошибок.

Плагин помогает там, где один исходный сайт используется как «эталон» или редакционная база, а затем материалы нужно перенести в выбранные сайты сети. По официальному описанию в репозитории WPMU DEV, поддерживается копирование страниц, записей, пользовательских типов записей, пользователей, изображений, комментариев, родительских страниц, дат публикации, а также активация плагинов, если они доступны в сети. Это не значит, что он переносит весь сайт как клон. Он работает именно с выбранными сущностями и режимами копирования.

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

Подходящие задачи

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

Где лучше выбрать другой подход

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

Перед массовым запуском сформулируйте задачу одним предложением: «Мне нужно скопировать конкретные записи и связанные данные» или «Мне нужно клонировать сайт целиком». Во втором случае этот плагин не должен быть первым выбором.

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

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

Права администратора сети и тестовый маршрут

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

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

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

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

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

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

Официальная поддержка WPMU DEV указывает, что плагин полагается на обычные механизмы WordPress для записей и метаданных. Это хорошо для стандартного редактора, обычных страниц и пользовательских типов записей, но может быть недостаточно для сложных конструкторов. В обсуждениях по Elementor и WPBakery встречается осторожная позиция: если конструктор хранит структуру в метаданных, перенос может сработать, но это не гарантирует полноценную совместимость со всеми внутренними связями, виджетами, шорткодами и глобальными шаблонами.

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

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

Установка проходит как у обычного плагина WordPress, но в Multisite важен контекст: плагин должен быть доступен сети, а интерфейс управления может находиться в админ-панели сети или в меню отдельного сайта в зависимости от версии и включённых модулей. После загрузки ZIP-файла откройте админ-панель сети, перейдите в раздел плагинов и активируйте Multisite Content Copier так, чтобы он мог работать с сайтами сети.

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

Мини-тест на одну страницу

Первую проверку удобно выполнить на простом материале. Создайте на исходном сайте страницу с коротким текстом, одним изображением и понятным заголовком, например «Тест копирования контента». Затем выберите один сайт назначения и выполните копирование с минимальным набором опций.

1. Откройте исходный сайт и убедитесь, что тестовая страница сохранена.
2. В интерфейсе плагина выберите исходный сайт, тип контента и конкретную страницу.
3. Выберите один сайт назначения, а не всю сеть.
4. Включите копирование изображений, если хотите проверить перенос вложений.
5. Запустите копирование и дождитесь завершения операции.
6. Откройте сайт назначения и проверьте страницу в админ-панели и в публичной части.

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

Что смотреть после первого запуска

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

Карта настроек: откуда копировать, куда отправлять и что переносить

Смысл настройки Multisite Content Copier можно свести к трём вопросам: источник, назначение и состав переносимых данных. Чем точнее вы ответите на них до запуска, тем меньше придётся чистить потом. В больших сетях особенно важно не пользоваться режимом «все сайты» как привычной кнопкой, а выбирать адресатов осознанно.

Источник контента

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

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

Сайты назначения, группы и шаблонные блоги

Плагин поддерживает разные варианты назначения: один сайт, все сайты, группы сайтов и интеграцию с шаблонными блогами WPMU DEV. По официальному описанию, интеграция с New Blog Templates работает для шаблонных блогов, созданных после установки Multisite Content Copier. Это важная деталь: если у вас уже были старые шаблоны до установки, не считайте, что они автоматически попадут в новый сценарий без проверки.

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

Типы контента и связанные данные

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

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

Работа с медиа, пользовательскими типами записей и конструкторами

На практике именно связанные данные создают больше всего вопросов. Обычный текст и заголовок копируются предсказуемее, чем изображение, блок конструктора, товарный тип записи, произвольное поле или галерея. Поэтому настройка после установки должна включать не только «что копировать», но и «как это будет жить на сайте назначения».

Медиа и галереи

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

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

Пользовательские типы записей

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

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

Конструкторы страниц и блоки

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

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

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

Представим сеть WordPress для организации с несколькими филиалами. На каждом подсайте нужны одинаковые стартовые страницы: «О филиале», «Документы», «Контакты», «Вопросы и ответы». Часть текста общая, но адреса, телефоны и локальные документы должны отличаться. Задача Multisite Content Copier - создать основу, а не заменить редакторов.

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

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

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

Шаги копирования

1. Создайте на исходном сайте родительскую страницу «Информация для посетителей» и вложенные страницы для документов, контактов и вопросов.
2. Добавьте одно тестовое изображение в каждую страницу, чтобы проверить перенос вложений.
3. В интерфейсе Multisite Content Copier выберите исходный сайт и тип контента «страницы».
4. Отметьте нужные страницы и включите перенос родительских связей, если этот параметр доступен в вашей версии.
5. Выберите группу сайтов филиалов или несколько конкретных сайтов назначения.
6. Включите копирование изображений, а комментарии оставьте выключенными, если они не нужны для стартовых страниц.
7. Запустите копирование сначала на один тестовый филиал, проверьте результат, затем повторите для остальных сайтов.

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

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

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

SEO, дубли и канонические ссылки после массового копирования

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

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

Безопасный вариант без кода

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

Аккуратная доработка через mu-плагин

Если у вашей сети есть технический специалист и подтверждённая необходимость добавлять каноническую ссылку к скопированным материалам, используйте отдельный mu-плагин, а не правку ядра WordPress, темы или самого Multisite Content Copier. Пример ниже показывает идею: при копировании сохраняется адрес исходной записи в метаполе, а в публичной части выводится тег canonical. Перед применением проверьте, что хук доступен в вашей версии плагина.

<?php
/*
Plugin Name: MCC Canonical Source Helper
Description: Adds a source canonical URL for copied posts when Multisite Content Copier exposes mcc_copy_post.
*/

add_action('mcc_copy_post', function ($source_post_id, $copied_post_id, $source_blog_id) {
    if (!$source_post_id || !$copied_post_id || !$source_blog_id) {
        return;
    }

    switch_to_blog((int) $source_blog_id);
    $source_url = get_permalink((int) $source_post_id);
    restore_current_blog();

    if ($source_url) {
        update_post_meta((int) $copied_post_id, '_mcc_source_canonical_url', esc_url_raw($source_url));
    }
}, 10, 3);

add_action('wp_head', function () {
    if (!is_singular()) {
        return;
    }

    $source_url = get_post_meta(get_the_ID(), '_mcc_source_canonical_url', true);
    if ($source_url) {
        echo '<link rel="canonical" href="' . esc_url($source_url) . "\" />\n";
    }
});

Размещайте такой файл в каталоге wp-content/mu-plugins/ только после теста на копии сети. Проверка простая: скопируйте одну страницу, откройте исходный код страницы назначения и найдите тег canonical. Откат тоже простой: удалите mu-плагин и очистите добавленное метаполе у тестовых записей. Если у вас уже работает SEO-плагин, сначала проверьте, не создаст ли он второй канонический тег.

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

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

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

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

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

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

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

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

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

Копия не появилась на сайте назначения

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

Что исправить

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

Изображения не отображаются или ведут на исходный сайт

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

Что исправить

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

Страница конструктора выглядит иначе

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

Когда откатить

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

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

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

Что исправить

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

Когда Multisite Content Copier будет удачным выбором

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

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

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