MainWP Pro Reports - Плагин WordPress

Руководство по настройке MainWP Pro Reports для клиентских отчётов

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

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

Особое внимание уделено токенам, данным MainWP Child Reports, выбору разделов в Report Data, настройке Custom Titles, безопасным правкам шаблона и ситуациям, когда отчёт выглядит пустым, не отправляется по расписанию или показывает значения не там, где ожидается.

Как Pro Reports превращает события сайта в отчёт для клиента

У MainWP Pro Reports есть важная особенность: он не является самостоятельным журналом всех действий на сайте. Расширение работает как отчётный слой внутри MainWP Dashboard, а сами события на обслуживаемых сайтах записывает бесплатный плагин MainWP Child Reports. Поэтому логика выглядит так: дочерний сайт фиксирует изменения, Dashboard синхронизирует данные, выбранный шаблон подставляет токены, а Pro Reports формирует HTML-просмотр, PDF и письмо.

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

Главный практический вывод: отчёт не появится "из прошлого". Если MainWP Child Reports был установлен только что, в первых отчётах могут быть пустые секции, даже если в другом месте Dashboard уже есть похожая история изменений. Pro Reports использует именно свой источник данных, а не любую соседнюю страницу со статистикой.

Роль Dashboard и дочернего сайта

Dashboard отвечает за создание, дизайн и отправку отчётов. На нём находятся вкладки создания отчёта, список отчётов, шаблоны, брендирование, письма, PDF-файлы и обзор состояния дочерних сайтов. Дочерний сайт отвечает за запись событий. Если Child Reports выключен, не обновлён или не успел собрать данные, Pro Reports может корректно создать файл, но внутри не будет нужных значений.

При настройке удобно думать не о "PDF", а о цепочке данные - правила - результат. Данные собирает Child Reports. Правила задаёт отчёт: тип, диапазон, шаблон, выбранные секции, получатель, брендирование. Результат проверяется в HTML-просмотре, PDF-файле и тестовой отправке.

Какие данные можно показывать

Документация описывает несколько типов токенов: клиентские, секционные, дата-токены и счётчики. Клиентские токены вроде [client.email] и [client.name] подставляют сведения о клиенте или сайте. Секционные токены создают циклы по записям за выбранный период. Дата-токены выводят конкретные значения внутри такого цикла, а счётчики показывают итоговое число событий вне секции.

Для пользователя это означает простую вещь: если в отчёте нужно показать список обновлённых плагинов, используется секция по обновлениям и внутри неё токены с названием, версией или автором действия. Если нужен только итог, достаточно счётчика. Ошибка с размещением токена часто приводит к тому, что в отчёте остаётся строка вида [plugin.updated.count] или появляется пустой блок.

Кому подходит такой отчётный сценарий, а кому он будет лишним

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

Когда продукт особенно уместен

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

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

Когда лучше не начинать с Pro Reports

Если вы не используете MainWP Dashboard или не готовы ставить MainWP Child Reports на дочерние сайты, начинать именно с этого расширения нет смысла. Оно построено вокруг экосистемы MainWP. Также продукт может быть лишним, если клиентам нужны не технические отчёты по обслуживанию, а коммерческая аналитика, рекламные показатели, финансовые сводки или отчёты из внешних систем без связи с обслуживанием WordPress.

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

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

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

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

Базовая готовность WordPress и MainWP

Сначала проверьте, что MainWP Dashboard нормально соединяется с дочерними сайтами. Если сайт не синхронизируется, Pro Reports не сможет надёжно понять состояние Child Reports и доступные данные. Затем убедитесь, что на дочернем сайте можно установить и активировать MainWP Child Reports. Для него в официальных источниках указано требование к PHP, поэтому старые окружения нужно проверять до начала настройки.

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

Что проверить на дочернем сайте

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

Проверка данных до первого отчёта

Перед созданием отчёта откройте на дочернем сайте путь WP Admin > Settings > MainWP Child > Child Reports или соответствующий путь с учётом вашего брендирования MainWP Child. Там должно быть видно, что события действительно записываются. Если записей нет, отчёт за этот период не сможет показать содержимое, даже если на сайте уже происходили обновления до установки Child Reports.

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

Установка и первый тест без пустого отчёта

Установка состоит из двух частей: Child Reports на дочерних сайтах и Pro Reports Extension на Dashboard. Важно не перепутать роли. Child Reports собирает события. Pro Reports на Dashboard создаёт отчёты. Если поставить только расширение на Dashboard, отчётный интерфейс будет доступен, но данных по сайтам может не быть.

Порядок установки

1. Установите MainWP Child Reports на дочерние сайты, которые должны попадать в клиентские отчёты.
2. Активируйте плагин и проверьте его настройки в админ-панели дочернего сайта.
3. Установите MainWP Pro Reports Extension на Dashboard.
4. Синхронизируйте сайты в MainWP Dashboard, чтобы Dashboard увидел состояние Child Reports.
5. Откройте MainWP Dashboard > Add-ons > Pro Reports и проверьте обзор Child Reports.
6. Создайте разовый отчёт за небольшой период и используйте Preview или Download PDF для проверки.

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

Первый отчёт лучше делать разовым

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

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

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

Настройка отчёта: тип, данные, брендирование и письмо

Раздел настройки - центральная часть работы с MainWP Pro Reports. Здесь определяется, что клиент увидит, как это будет выглядеть, каким письмом уйдёт отчёт и какие сайты попадут в конкретную отправку. Хорошая настройка не сводится к выбору шаблона. Нужно связать назначение отчёта, источник данных, язык заголовков, визуальное оформление и проверку доставки.

Выбор типа отчёта

Pro Reports поддерживает два рабочих сценария: регулярный и разовый. Регулярный отчёт запускается по расписанию и подходит для постоянных клиентов. Разовый отчёт создаётся вручную за выбранный диапазон и полезен для аудита, завершения проекта, внеплановой проверки или первого теста.

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

Вкладка Custom Content

Custom Content отвечает за человеческую часть отчёта: заголовок первой страницы, вступление и закрывающее сообщение. Эти поля поддерживают токены, поэтому их удобно делать не только красивыми, но и персональными. Например, в обращении можно использовать имя клиента, а в закрывающем блоке - понятное объяснение, что отчёт покрывает выбранный период обслуживания.

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

Вкладка Report Data

Report Data определяет, какие разделы попадут в отчёт. У каждой секции можно выбрать показ, скрытие или скрытие при отсутствии данных. Это одна из самых полезных настроек, потому что она защищает клиента от пустого документа, а вас - от ручного удаления блоков перед каждой отправкой.

Для типового care plan включайте только те секции, которые реально отражают работу. Если вы не ведёте аналитику через MainWP, не нужно оставлять аналитический блок просто для красоты. Если резервные копии выполняются отдельным инструментом, который не отдаёт данные в Pro Reports, лучше объяснить это во вводном тексте или оставить секцию скрытой, чем показывать пустой блок.

Когда использовать Hide if empty

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

Вкладка Custom Branding

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

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

Вкладка Custom Titles

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

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

Настройки письма

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

Для первого регулярного отчёта не отправляйте письмо сразу клиенту. Укажите свой тестовый адрес, проверьте тему, тело письма, вложение и имя PDF. Затем верните клиентский токен в поле Send email to и сделайте ещё одну контрольную отправку на внутренний адрес через дубликат отчёта или тестовый вариант.

Токены, шаблоны и клиентские данные без путаницы

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

Клиентские и site-level значения

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

Перед автоматизацией проверьте минимум четыре поля: имя клиента, email, название сайта и URL сайта. Если [client.email] используется в поле получателя, но значение не заполнено, отчёт не сможет уйти так, как вы ожидаете. Если [client.name] пустой, письмо будет выглядеть неаккуратно.

Секционные токены и счётчики

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

Plugins installed: [plugin.installed.count]

[section.plugins.installed]
  Plugin: [plugin.name]
  Installed: [plugin.installed.date]
[/section.plugins.installed]

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

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

Встроенные шаблоны подходят для старта. Пользовательский шаблон нужен, если вы хотите изменить структуру PDF глубже: убрать лишние блоки на уровне PHP-файла, добавить изображения, ограничить число строк в таблице, переупорядочить секции или подготовить фирменный формат агентства. Документация рекомендует копировать встроенный PHP-шаблон и загружать копию в /wp-content/uploads/mainwp/report-templates/.

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

Как выбрать секции отчёта под клиента, а не под полный список возможностей

Одна из типичных ошибок при первом знакомстве с MainWP Pro Reports - включить почти все доступные блоки, потому что "раз данные есть, пусть клиент видит". На практике такой отчёт быстро становится шумным. Клиенту не всегда нужны все таблицы, а агентству не всегда выгодно показывать технические детали без контекста. Полезный отчёт строится от вопроса клиента, а не от количества токенов в документации.

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

Обязательные секции: что подтверждает выполненную работу

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

Для обязательных секций лучше писать понятные заголовки через Custom Titles. Вместо технического "Plugins Updated" для клиента можно использовать формулировку вроде "Обновления плагинов". Если отчёт идёт на русском языке, заголовки и вводный текст лучше переводить заранее, а не оставлять смесь английских секций и русских комментариев.

Проверка обязательной секции

Выберите один дочерний сайт, где заведомо есть событие нужного типа, создайте разовый отчёт за период с этим событием и проверьте, появилась ли строка в PDF. Если строки нет, не прячьте секцию настройкой Hide if empty, пока не найдёте причину. Сначала проверьте Child Reports, синхронизацию и токены.

Условные секции: когда данные полезны, но не гарантированы

Условные секции подходят для событий, которые происходят не каждый период: новые пользователи, изменения страниц, комментарии, security-события, отдельные результаты проверок. Здесь Hide if empty обычно уместен, потому что клиенту не нужно видеть пустую таблицу только ради того, чтобы отчёт выглядел длиннее.

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

Внутренние секции: что полезно команде, но перегружает клиента

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

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

Как объяснить пустой период без лишней тревоги

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

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

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

Практический сценарий: ежемесячный отчёт по обслуживанию сайта

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

Цель

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

Подготовка

• MainWP Dashboard подключён к сайту клиента.
• MainWP Child Reports установлен на дочернем сайте и уже записывает события.
• В нужных интеграциях MainWP есть данные, если вы хотите показывать резервные копии, мониторинг, аналитику или безопасность.
• В клиентских данных заполнены email, имя клиента, название сайта и URL.
• Есть тестовый email для внутренней проверки перед первой отправкой клиенту.

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

1. Откройте MainWP Dashboard > Add-ons > Pro Reports > Create Report.
2. Создайте сначала One-time отчёт за небольшой диапазон и выберите базовый шаблон.
3. Во вкладке Custom Content напишите короткое вступление: что покрывает отчёт и какие работы отражены.
4. Во вкладке Report Data оставьте только полезные секции: WordPress, обновления плагинов и тем, резервные копии, uptime и другие подтверждённые блоки.
5. Для редких событий используйте Hide if empty, но не скрывайте секции, которые должны показывать ключевую работу, пока не проверили источник данных.
6. Во вкладке Custom Branding добавьте логотип и умеренные брендовые цвета.
7. Во вкладке Custom Titles замените технические заголовки на понятные клиенту формулировки.
8. В настройках письма временно укажите свой email, проверьте тему, тело письма и вложение.
9. Скачайте PDF и откройте его в нескольких обычных просмотрщиках или браузере.
10. Если всё корректно, создайте регулярный отчёт на основе проверенной структуры и верните клиентский токен получателя.

Ожидаемый результат и проверка

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

Нюанс, который часто мешает

Если в отчёте нет обновлений, но вы видите их в другой части MainWP, проверьте, использует ли эта страница тот же источник данных. В обсуждениях MainWP встречается ситуация, когда пользователь видит обновления в Dashboard Insights, но Pro Reports использует данные MainWP Child Reports. Это разные источники, поэтому установка Child Reports после события не делает старую запись доступной для Pro Reports.

Практичные идеи применения в работе агентства

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

Короткий отчёт для владельца малого сайта

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

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

Расширенный отчёт для eCommerce или активного проекта

Для магазина или активного сайта отчёт может быть подробнее. Если в вашей связке MainWP есть данные по uptime, резервным копиям, security, performance или WooCommerce-статистике через соответствующие инструменты, их можно включать осознанно. Но eCommerce-клиентам важен не только список обновлений. Им нужен ответ: сайт работал, заказы не прерывались, резервные копии были, критичные технические риски контролировались.

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

Отчёт после технического аудита

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

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

Внутренний отчёт для команды

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

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

Проверка PDF, письма и данных перед автоматической отправкой

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

Что смотреть в HTML-просмотре

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

Что смотреть в PDF

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

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

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

Контрольная проверка перед расписанием: отчёт вручную создаётся, HTML-просмотр показывает данные, PDF открывается, письмо приходит на тестовый адрес, а в Dashboard видно, что дочерний сайт активен и Child Reports собирает события.

Безопасные улучшения шаблонов без правки ядра

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

Ограничить количество строк в длинной секции

Если за период было много обновлений или резервных копий, длинная таблица может забить весь отчёт. В документации MainWP описан безопасный подход: создать пользовательскую копию шаблона, добавить CSS ID к нужному <tbody> и скрыть строки после заданного количества. Ниже пример для секции резервных копий. Используйте его только в копии пользовательского шаблона.

#backuptable tr {
  display: none;
}

#backuptable > tr:nth-child(-n+5) {
  display: table-row;
}

Число 5 меняется на нужный лимит. После правки загрузите шаблон обратно в /wp-content/uploads/mainwp/report-templates/, выберите его в отчёте и проверьте PDF. Откат простой: верните прежний шаблон или удалите CSS-правило из копии.

Добавить изображение в пользовательский шаблон

Если клиентский отчёт требует отдельной иллюстрации, баннера раздела или поясняющей графики, документация предлагает добавлять изображение в PHP-шаблон через обычный HTML-код. Важно, чтобы URL изображения был доступен Dashboard и PDF-генератору. Если картинка не появляется в PDF, проверьте доступность URL, SSL и журналы PDF-генерации.

<p><img src="https://example.com/uploads/report-section.png" alt="Plugins section image"></p>

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

HTML-only отчёт как особый сценарий

Официальная инструкция MainWP показывает, что PDF-вложение можно отключить фильтром mainwp_pro_reports_email_attachments и отправлять только HTML-письмо. Это не базовый сценарий для всех: Pro Reports изначально ориентирован на PDF-данные, поэтому HTML-only стоит применять, когда клиент действительно предпочитает письмо без вложения и вы готовы поддерживать отдельный email-шаблон.

add_filter( 'mainwp_pro_reports_email_attachments', 'mycustom_mainwp_pro_reports_email_attachments', 10, 4 );
function mycustom_mainwp_pro_reports_email_attachments( $attachments, $html_to_pdf, $report, $site_id = false ) {
   return '';
}

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

Почему отчёт пустой, не отправляется или PDF ведёт себя странно

Диагностика MainWP Pro Reports почти всегда начинается с вопроса: на каком этапе цепочки пропал результат? События могли не записаться на дочернем сайте, Dashboard мог не увидеть Child Reports, шаблон мог неправильно использовать токены, расписание могло не сработать из-за WP-Cron, а PDF мог открыть проблему уже после генерации.

Отчёт создаётся, но секции пустые

Симптом: PDF или HTML-просмотр открывается, строки и заголовки есть, но значения отсутствуют либо отдельные секции пустые. Иногда видны сырые токены вместо чисел.

Что проверить: откройте Child Reports на самом дочернем сайте и убедитесь, что нужные события были записаны в выбранный период. Проверьте, что Child Reports был установлен до этих событий, а не после. Затем проверьте, что используемые секции включены в Report Data и не скрыты ошибочно.

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

Сайт не виден в обзоре Child Reports

Симптом: вы уверены, что плагин установлен, но в Dashboard на странице Pro Reports сайт не отображается или состояние не обновляется.

Что проверить: выполните синхронизацию сайтов в MainWP Dashboard. Проверьте, активен ли MainWP Child Reports на дочернем сайте, не скрыт ли он брендированием и нет ли проблем с подключением MainWP Child.

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

Регулярный отчёт отправляется только после открытия админки

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

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

Как исправить: проверьте WP-Cron на Dashboard, настройте регулярный внешний ping или системный cron в рамках нормальной администраторской практики WordPress, затем создайте тестовый регулярный отчёт на внутренний адрес.

PDF открывается с предупреждением или без изображений

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

Что проверить: откройте PDF в другом просмотрщике и браузере, протестируйте стандартный шаблон без кастомных изображений, проверьте доступность URL изображений и SSL. В обсуждениях MainWP встречались случаи, где проблема зависела от PDF-просмотрщика или от доступа PDF-генератора к внешнему изображению.

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

В отчёте остались сырые токены

Симптом: вместо данных видны строки вроде [plugin.updated.count] или [section.plugins.updated].

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

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

Видео по пользовательским шаблонам Pro Reports

Для визуального закрепления полезнее всего точное видео MainWP о создании пользовательских шаблонов. Оно закрывает намерение "как пользоваться MainWP Pro Reports для шаблонов": показывает, зачем нужны PHP-шаблоны, где искать встроенные файлы и как использовать токены в отчёте. Видео стоит смотреть после базовой настройки, когда вы уже понимаете разницу между Child Reports, отчётом и шаблоном.

Обратите внимание на три момента: выбор встроенного шаблона как основы, размещение файла в директории пользовательских report-templates и логику токенов. Эти шаги лучше повторять сначала на тестовом отчёте, а не на боевом шаблоне клиента.

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

MainWP Pro Reports стоит использовать, если вы уже работаете с MainWP Dashboard, обслуживаете несколько WordPress-сайтов и хотите превратить технические события в понятный клиентский отчёт. Сильная сторона продукта - связка Child Reports, настраиваемых PDF-шаблонов, токенов, брендирования, выбора секций и регулярной отправки.

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

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