Paid Memberships Pro Add Member From Admin - Плагин WordPress

Руководство по Paid Memberships Pro Add Member From Admin для ручного добавления участников

Paid Memberships Pro Add Member From Admin полезен там, где администратору нужно быстро создать пользователя, назначить ему уровень доступа и при необходимости зафиксировать заказ без прохождения обычной формы оформления на сайте. В этом руководстве разберём не только порядок установки, но и рабочую логику: когда этот путь безопасен, какие поля заполнять, как проверять результат и где чаще всего появляются ошибки.

Материал рассчитан на владельца membership-сайта, менеджера сообщества, администратора ассоциации, редактора онлайн-курса или разработчика, который поддерживает сайт на WordPress и Paid Memberships Pro. Здесь не будет пересказа карточки продукта. Вместо этого вы получите практическую инструкцию: подготовка сайта, настройка уровней, создание участника, работа с заказами, служебные заметки, диагностика и выбор между этим add-on и встроенными возможностями PMPro.

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

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

В обычной модели Paid Memberships Pro посетитель выбирает уровень, переходит на страницу оформления, заполняет данные, оплачивает тариф при необходимости и получает доступ. Это правильный путь для большинства новых клиентов, потому что он создаёт пользователя, membership-статус, заказ, письма и платёжные записи в одном понятном процессе.

Paid Memberships Pro Add Member From Admin закрывает другую задачу. Он нужен, когда участник уже договорился с командой вне сайта, когда доступ выдаётся бесплатно, когда оплата пришла банковским переводом или чеком, когда нужно перенести одного человека из старой базы, быстро исправить ошибку поддержки или добавить участника ассоциации после личного подтверждения. В таких случаях заставлять человека заново проходить публичное оформление бывает неудобно.

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

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

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

• Выдача бесплатного или компенсационного доступа одному участнику.
• Ручное добавление участника после оплаты наличными, банковским переводом или чеком.
• Оперативное исправление доступа, когда пользователь уже есть в WordPress, но membership-запись отсутствует или заполнена неверно.
• Добавление члена ассоциации, клуба или учебной группы после внутренней проверки.
• Пробный перенос нескольких участников перед массовым импортом через CSV.

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

Если нужно массово перенести сотни пользователей, ручная форма быстро станет источником ошибок. Для такой задачи лучше использовать Import Members From CSV или другой проверенный импорт с предварительной подготовкой таблицы. Если нужно принять онлайн-платёж и создать регулярную подписку, правильнее провести пользователя через публичное оформление или выполнить оформление от имени пользователя, если это допустимо в вашей рабочей политике. Если сайт уже работает на свежей версии Paid Memberships Pro, обязательно сравните add-on со встроенной кнопкой + Add Member на странице Memberships > Members, потому что разработчик рекомендует именно встроенный путь для новых сайтов.

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

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

Начните с уровней. В PMPro каждый участник получает доступ через membership-level. Если уровни ещё не созданы, администратор физически не сможет назначить нужный вариант доступа. Для сайта с несколькими группами уровней проверьте, как они соотносятся между собой: одни уровни могут быть взаимоисключающими, другие - добавочными. Сам add-on указан разработчиком как решение для сайтов, где участник ограничен одним активным уровнем, поэтому на проектах с несколькими одновременными уровнями нужно быть особенно осторожным.

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

Мини-чеклист перед включением

• Paid Memberships Pro установлен, активирован и настроен хотя бы на базовом уровне.
• Создан нужный membership-level и понятна его цена, срок действия и правило доступа.
• Назначены страницы PMPro: account, checkout, confirmation, invoice, cancel и другие обязательные страницы.
• Понятно, кто имеет право вручную создавать участников и заказы.
• Есть резервная копия перед изменениями на рабочем сайте.
• Команда договорилась, когда использовать add-on, а когда отправлять пользователя на обычное оформление.

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

Нюанс с письмами и ожиданиями пользователя

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

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

Установка проходит как у других add-ons Paid Memberships Pro. В админ-панели откройте Memberships > Add Ons, найдите нужный add-on и нажмите Install. Если установка выполняется вручную, загрузите ZIP через Plugins > Add New > Upload Plugin, затем активируйте плагин на странице плагинов WordPress.

После активации в меню Memberships должна появиться страница Add Member. Это и есть основной рабочий экран add-on. Если пункт не появился, не начинайте создавать пользователей через обходные способы. Сначала проверьте, активен ли сам Paid Memberships Pro, есть ли у текущего пользователя права администратора или Membership Manager, не отключён ли add-on, не скрыт ли пункт меню из-за плагина управления ролями.

Быстрая проверка после активации

1. Откройте Memberships > Add Member и убедитесь, что форма загружается без ошибок.
2. Проверьте, что в списке уровней видны нужные membership-levels.
3. Убедитесь, что поля пользователя включают email, имя, фамилию, пароль или случайный пароль и роль WordPress.
4. Посмотрите, есть ли блоки оплаты, суммы заказа и внутренних заметок.
5. Не создавайте реального участника первым тестом. Сначала используйте тестовый email и понятную внутреннюю пометку.

Если сайт уже работает на версии PMPro, где есть встроенный путь Memberships > Members > + Add Member, сравните оба интерфейса до того, как обучать команду. На новых проектах часто разумнее использовать встроенную страницу, а add-on оставить только для старых процессов, где форма уже знакома менеджерам и её поведение проверено.

Как устроена форма Add Member и почему поля нельзя заполнять на автомате

Форма Add Member объединяет несколько действий: создание пользователя WordPress, назначение уровня PMPro, настройку срока доступа и создание административной записи о заказе. Из-за этого она кажется простой, но каждое поле влияет на разные части сайта.

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

Блок membership-level определяет, какой закрытый контент откроется пользователю. В PMPro доступ обычно строится вокруг уровня, а не вокруг произвольной роли WordPress. Поэтому нельзя считать, что создание пользователя само по себе открыло материалы. Нужен именно корректно назначенный уровень.

Срок действия и дата окончания

Официальная документация add-on подчёркивает, что срок окончания, настроенный в самом membership-level, не подставляется в форму автоматически. Это значит, что администратор должен вручную понимать, какую дату указать. Ошибка здесь приводит к двум типичным проблемам: участник получает бессрочный доступ вместо временного или теряет доступ раньше, чем должен.

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

Оплата, сумма заказа и ручная запись

В форме add-on есть блок оплаты, но он ограничен ручными вариантами вроде cash or check. Документация прямо говорит, что add-on не умеет списывать оплату с пользователя через админ-панель. Это не баг, а граница сценария. Если человек платит картой, обычная публичная страница оформления остаётся более точным и безопасным путём.

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

Заметки администратора

User Notes - один из самых практичных элементов add-on, если им пользоваться дисциплинированно. Официальная документация указывает, что такие заметки сохраняются в wp_usermeta с ключом user_notes, а для удобного отображения их можно вывести через User Fields: создать группу, скрыть её на checkout, показать только администраторам в профиле и добавить поле типа Text Area с именем user_notes.

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

Настройка после установки: роли, уровни, заметки и рабочие правила

У Add Member From Admin почти нет отдельной страницы настроек, поэтому настройка происходит вокруг него: в ролях WordPress, membership-levels, User Fields, письмах и правилах команды. Это важный момент. Если после активации сразу начать создавать участников, процесс может работать технически, но быть слабым организационно.

Ограничьте круг пользователей с доступом к форме

Если на сайте работает Membership Manager Role, назначайте эту роль только тем, кто реально ведёт membership-базу. Такой сотрудник может управлять членством, участниками, заказами и отчётами, но не получает полный административный доступ ко всему WordPress-сайту. Для многих команд это лучше, чем давать обычному менеджеру роль администратора.

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

Подготовьте уровни для ручного сценария

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

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

Настройте admin-only User Notes

Чтобы заметки не терялись, создайте отдельную группу User Fields. В Memberships > Settings > User Fields добавьте группу, установите Show fields at checkout? в No, а Show fields on user profile? - в Yes (only admins). Затем добавьте поле с именем user_notes и типом Text Area. После сохранения администратор сможет видеть и редактировать заметки на профиле пользователя.

Лучше заранее договориться о формате заметки. Например: Источник: заявка ассоциации. Доступ: Professional. Основание: офлайн-оплата подтверждена менеджером. Следующая проверка: конец периода доступа. Такой текст помогает любому члену команды понять контекст без звонков и пересылки писем.

Подготовьте письмо участнику

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

Мини-итог настройки: сам add-on даёт форму, а качество процесса дают правила команды. Ограничьте права, подготовьте уровни, включите admin-only notes и используйте единый шаблон сообщения участнику.

Практический пример: добавить участника ассоциации после офлайн-оплаты

Разберём сценарий, который хорошо соответствует назначению Paid Memberships Pro Add Member From Admin: член ассоциации оплатил взнос вне сайта, менеджер получил подтверждение и должен выдать доступ к закрытым материалам. Цель - создать аккаунт, назначить правильный уровень, зафиксировать ручной заказ и оставить внутреннюю заметку.

Подготовка

Перед созданием участника убедитесь, что уровень ассоциации уже существует, срок действия понятен, а менеджер имеет права на страницу Memberships > Add Member. Подготовьте email участника, имя, фамилию, подтверждение оплаты и текст заметки. Если участник уже есть в WordPress, сначала найдите его через Users или Memberships > Members, чтобы не создать дубль.

Шаги

1. Откройте Memberships > Add Member.
2. Заполните email, имя и фамилию участника. Для пароля используйте случайный вариант или стандартный механизм восстановления пароля.
3. Выберите обычную роль WordPress для участника, не административную роль.
4. Назначьте membership-level, который соответствует оплаченной категории.
5. Укажите срок окончания, если доступ должен завершиться автоматически.
6. В блоке оплаты выберите ручной способ, если он соответствует реальному способу оплаты.
7. Заполните сумму заказа и заметку: откуда пришёл платёж, кто подтвердил, какой доступ выдан.
8. Сохраните форму и дождитесь создания пользователя.

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

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

Проверка

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

Нюанс, который часто забывают

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

Заказы, отчёты и отличие доступа от подписки

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

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

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

Как не сломать отчётность

• Используйте понятные order notes, чтобы отличать офлайн-оплату от бесплатной выдачи.
• Не записывайте сумму, если оплаты не было и это исказит внутренние отчёты.
• Не отмечайте ручной заказ как подтверждение gateway-платежа, если платёж прошёл вне gateway.
• Регулярно сверяйте Memberships > Orders с фактическими платежами, если вручную добавляете платные доступы.
• Для массового переноса подписок используйте импорт и отдельный план миграции, а не десятки ручных записей.

Что делать с уже существующим пользователем

Если пользователь уже есть в WordPress, не создавайте второй аккаунт с похожим email. Откройте список участников или пользователей и проверьте текущую запись. В большинстве случаев лучше обновить существующего пользователя через экран PMPro Members, добавить или изменить membership-level и только затем создать заказ, если он нужен. Дубли пользователей ломают поддержку: человек не понимает, под каким email входить, а менеджер видит оплату в одном профиле и отсутствие доступа в другом.

Как выбрать между add-on, встроенным PMPro и импортом

Главная ловушка при работе с ручным добавлением - пытаться решить одним экраном все задачи управления участниками. На практике у PMPro есть несколько путей, и каждый хорош в своём масштабе. Add Member From Admin удобен как быстрый административный инструмент для одного участника. Встроенный экран PMPro лучше подходит для текущей логики продукта. CSV-импорт нужен, когда данных много. Публичное оформление нужно, когда пользователь должен пройти обычную оплату или создать подписку.

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

После такой матрицы add-on становится не "старой кнопкой для всего", а осознанным инструментом. Это снижает риск, что менеджер вручную создаст заказ для регулярной подписки, забудет про письмо или назначит временный уровень без даты окончания.

Отдельный случай: несколько активных membership-levels

Официальная страница add-on отмечает, что он рассчитан на сайты, где участник ограничен одним активным membership-level at a time. Если ваш PMPro-сайт использует несколько одновременных уровней, группы уровней, дополнительные пакеты доступа или сложные учебные связки, проверьте ручной сценарий на тестовом пользователе. Важно понять, что именно произойдёт: новый уровень заменит старый, добавится параллельно или потребует другого интерфейса управления.

На таких проектах не стоит полагаться на память менеджера. Сделайте тест: пользователь с одним уровнем, пользователь без уровня, пользователь с добавочным уровнем. Для каждого запишите, какой путь нужен. Если поведение add-on не соответствует текущей архитектуре уровней, используйте встроенный Edit Member или отдельный процесс, рекомендованный документацией PMPro.

Как вести внутренний журнал ручных действий

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

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

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

Для этого add-on не стоит выдумывать сложные доработки. Официально подтверждены два hook-события: pmpro_add_member_fields и pmpro_add_member_added. Они полезны разработчику, но без конкретной задачи лучше не добавлять код. Для большинства сайтов безопаснее настроить роли, User Fields, заметки и внутреннюю инструкцию.

Один небольшой snippet может быть уместен, если команда хочет после ручного добавления участника сохранить дополнительную внутреннюю отметку в user meta. Ниже пример использует документированный action pmpro_add_member_added. Он не отправляет письма, не меняет уровень и не вмешивается в оплату. Его задача - зафиксировать техническую отметку, что пользователь был создан через административную форму.

Размещайте такой код только через Code Snippets или дочернюю тему, а не в файлах ядра WordPress, PMPro или add-on. Перед применением проверьте на тестовом сайте.

add_action( 'pmpro_add_member_added', function( $user_id, $user, $morder ) {
    if ( empty( $user_id ) ) {
        return;
    }

    update_user_meta( $user_id, 'pmpro_manual_add_source', 'add_member_from_admin' );
}, 10, 3 );

Проверка простая: создайте тестового пользователя через Memberships > Add Member, откройте его профиль или посмотрите user meta через безопасный административный инструмент. Если отметка не нужна, отключите snippet. Если сайт использует строгую политику персональных данных, заранее согласуйте, какие внутренние поля можно хранить.

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

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

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

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

1. Откройте Memberships > Members и найдите участника по email.
2. Проверьте уровень, статус, дату начала и дату окончания.
3. Если создавался заказ, откройте Memberships > Orders и найдите запись по пользователю.
4. Проверьте notes: понятно ли другому администратору, почему доступ создан вручную.
5. Откройте Users > All Users и убедитесь, что роль WordPress не выдана слишком широко.

Проверка на сайте

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

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

Проверка сообщения пользователю

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

Когда стоит использовать Paid Memberships Pro Add Member From Admin

Paid Memberships Pro Add Member From Admin будет удачным выбором, если у вас уже есть работающий PMPro-сайт и нужен контролируемый административный путь для единичных ручных добавлений: офлайн-оплата, компенсационный доступ, участник ассоциации, поддержка после ошибки или небольшой перенос. Он особенно полезен, когда менеджеру нужно выполнить всё в одном месте: создать пользователя, выбрать уровень, задать срок, оставить заметку и при необходимости создать заказ.

Не используйте его там, где нужна автоматическая оплата, регулярная подписка у gateway, массовый импорт или современный встроенный процесс PMPro, который уже закрывает задачу лучше. Перед внедрением проверьте роли, уровни, даты, письма и порядок сверки заказов. После первого тестового участника обязательно пройдите полный путь проверки: профиль, membership-level, order, заметка, закрытая страница и сообщение пользователю.

Если после проверки вы понимаете, что add-on подходит вашему сценарию, можно скачать ZIP-архив и протестировать его на копии сайта или staging-окружении. Такой подход позволит оценить форму, обучить менеджера и не рисковать реальными участниками на рабочем сайте.