PaidListings Add-on for JReviews - Расширение Joomla

Руководство по настройке PaidListings Add-on for JReviews для платных объявлений в Joomla

PaidListings Add-on for JReviews нужен не просто для того, чтобы поставить цену на добавление записи. Это надстройка над уже собранным каталогом JReviews, где платный план управляет доступом к публикации, сроком размещения, числом изображений, набором дополнительных полей, статусом featured, продлением и апгрейдом существующей записи. В этом руководстве разберём, как подойти к настройке без хаоса: подготовить категории, создать планы, подключить обработчики оплаты, проверить личный кабинет пользователя, настроить уведомления, купоны, срок действия заказов и безопасно перевести уже существующие записи в платный режим.

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

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

Какую задачу решает платная модель внутри JReviews

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

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

Главное отличие PaidListings от обычного платёжного компонента в том, что оплата встроена в жизненный цикл записи JReviews. Платный план может применяться при новой отправке, при продлении и при апгрейде. Поэтому настраивать нужно не только "кнопку оплаты", а всю цепочку: категория, план, поля, медиа, срок, заказ, уведомления, личный кабинет, cron и результат на публичной странице.

Что расширение делает полезного для администратора

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

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

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

Кому расширение подходит, а где лучше не усложнять сайт

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

Хорошие сценарии для PaidListings

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

Для агентства или вебмастера PaidListings удобен тем, что остаётся внутри экосистемы JReviews. Не нужно собирать отдельный магазин, отдельную форму и отдельную таблицу оплаченных услуг. Заказ связан с записью, а не живёт отдельно от каталога. Это снижает риск, что администратор получит оплату, но забудет вручную включить нужные поля или продлить объявление.

Ситуации, где расширение может быть лишним

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

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

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

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

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

Базовая совместимость и сервер

Проверьте требования JReviews для вашей версии Joomla и PHP, а также наличие обязательных PHP-расширений. В официальной документации отдельно указаны требования к установке пакетов и типичная проблема Joomla с установкой S2Framework на серверах, где ограничение nofile слишком низкое. В руководстве по PaidListings это особенно важно, потому что сбой базового JReviews или add-on установки часто ошибочно воспринимают как проблему платных планов.

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

Структура категорий и типов записей

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

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

Меню, личный кабинет и права доступа

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

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

Установка add-on и безопасная первичная проверка

Установка add-on выполняется через механизм JReviews App Store в админ-панели JReviews, если подписка и доступ к add-on активны. Для новых установок официальная документация рекомендует сначала установить S2Framework и JReviews, а add-ons ставить уже после базовой настройки. В этом руководстве мы не разбираем лицензионные действия и покупку продукта, потому что для администратора важнее правильно включить уже доступное расширение и проверить его в изолированном сценарии.

Порядок первичного включения

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

1. Убедитесь, что JReviews уже имеет рабочую директорию, категорию, тип записи и меню отправки.
2. Создайте или проверьте меню PaidListings My Account, чтобы пользователь видел заказы и записи.
3. Включите хотя бы один обработчик оплаты, для первого теста удобнее использовать Offline.
4. Создайте простой бесплатный или одноразовый план для тестовой категории.
5. Отправьте запись с публичной части сайта от имени обычного пользователя.
6. Проверьте заказ в админ-панели PaidListings и вручную отметьте успешный OFFLINE платёж, если тестируете этот обработчик.
7. Откройте запись на сайте и убедитесь, что поля, медиа и статус соответствуют выбранному плану.

Такой тест показывает, работает ли связка "план - заказ - запись" до подключения внешних платежей. Если ошибка появляется уже здесь, её нужно искать в категориях, правах, меню, планах или базовой настройке JReviews. Если offline-сценарий проходит успешно, можно переходить к PayPal, Stripe или другому доступному обработчику с учётом их требований.

Что считать успешной установкой

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

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

Планы размещения: базовые тарифы, апгрейды и сроки действия

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

Базовый план и план апгрейда

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

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

Одноразовая оплата, подписка и бесплатный период

PaidListings поддерживает одноразовые платежи, подписки и бесплатные или пробные планы. Подписки доступны не во всех обработчиках: в документации указаны PayPal и Stripe, а для Stripe требуется отдельный Stripe Payments Add-on. Важно не обещать пользователю автоматическое продление там, где выбранный обработчик его не поддерживает.

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

Что происходит при истечении плана

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

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

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

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

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

Как связать план с набором полей

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

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

Медиа и лимиты изображений

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

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

Featured-статус и осторожность с поиском

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

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

Оплата, обработчики и тестовый путь пользователя

PaidListings поддерживает несколько обработчиков оплаты. В документации перечислены Offline, PayPal, 2Checkout, Stripe через отдельный Stripe Payments Add-on, Mollie и Coinbase через отдельные add-ons, а также балльные обработчики для EasySocial, JomSocial и AlphaUserPoints. Не все обработчики равны по возможностям: например, подписки указаны для PayPal и Stripe, а Offline подходит для ручной обработки.

Почему сначала нужен Offline-тест

Первый тест через Offline отделяет ошибки PaidListings от ошибок внешнего платёжного сервиса. Если заказ не создаётся, план не применяется или запись не получает нужный статус, проблема не в PayPal и не в Stripe. Если offline-путь работает, но внешний обработчик возвращает пользователя с ошибкой, тогда можно смотреть настройки конкретного платёжного сервиса, домен, режим тестирования и заголовки безопасности.

Для обработки offline-заказа документация рекомендует открыть заказ в разделе Orders add-on администрирования, отметить Successful OFFLINE payment и сохранить заказ. После этого проверьте публичную запись, личный кабинет пользователя и уведомления. Такой ручной тест полезен даже если вы не планируете принимать офлайн-платежи в реальности.

Возврат после оплаты и CSP в Joomla

Особое внимание нужно уделить возврату пользователя после внешней оплаты. В документации PaidListings описана ситуация с Joomla HTTP Headers Plugin и заголовками безопасности: при некоторых сценариях возврата PayPal через post request пользователь может быть автоматически разлогинен, если политика не разрешает нужные источники. Документация предлагает настраивать Content-Security-Policy с директивой connect-src для собственного сайта и доменов PayPal, включая sandbox.

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

Что должен увидеть пользователь

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

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

Купоны, налоги, письма и отслеживание событий

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

Купоны без хаоса в тарифах

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

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

Налоги и итоговая сумма

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

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

Уведомления и expiration reminders

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

Проверьте темы писем, тело письма, теги и адрес администратора. Для писем о завершении срока используйте понятные формулировки: что произойдёт с записью, где продлить, что изменится после истечения. Если cron не настроен, expiration-задачи могут не выполняться вовремя, поэтому уведомления о сроках нельзя тестировать отдельно от cron.

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

На странице продукта и в документации указано, что в PaidListings есть поля для кода отслеживания по заранее определённым действиям, а в коде можно использовать специальные теги вроде {order_id}, {order_amount} и {plan_name}. Это удобно для аналитики, потому что не нужно редактировать файлы шаблона ради базового отслеживания заказа.

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

Практический пример: платный каталог локальных услуг

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

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

Хотим получить каталог, где зарегистрированный пользователь может добавить компанию в категорию "Услуги". Базовая публикация даёт краткое описание, адрес и несколько изображений. Платный апгрейд добавляет расширенное описание, дополнительные контакты, больше изображений и статус выделенной записи. До начала должны быть настроены JReviews, категория Joomla, тип записи, группы полей, меню отправки записи и меню PaidListings My Account.

Что подготовить в JReviews

• Категорию Joomla, которая уже подключена к JReviews через Categories Manager.
• Тип записи для компаний или услуг с базовыми и расширенными группами полей.
• Права отправки записей для зарегистрированных пользователей и модерацию для новых публикаций, если она нужна.
• Тестового пользователя без административных прав.
• Offline обработчик оплаты для первого полного теста.

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

1. Создайте базовый Base план для категории "Услуги". Включите только те поля и медиа, которые должны быть доступны всем владельцам карточек.
2. Создайте Upgrade план для расширенной карточки. Свяжите его с нужным базовым планом, добавьте расширенные поля, увеличенный лимит изображений и, если требуется, статус выделенной записи.
3. Настройте срок действия. Для базовой карточки можно использовать длительный или бессрочный вариант, а для апгрейда - ограниченный период, если каталог продаёт видимость на срок.
4. Проверьте, что планы назначены нужной категории и не показываются там, где пользователь не должен их видеть.
5. От лица тестового пользователя отправьте новую запись, выберите базовый план и завершите заказ через Offline.
6. В админ-панели откройте заказ и отметьте успешный offline-платёж, затем проверьте публичную карточку.
7. Из личного кабинета пользователя выполните апгрейд записи и снова проверьте заказ, поля, изображения и статус выделения.

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

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

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

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

Если вы изменили план после того, как заказ уже создан, существующая запись может не получить новые поля автоматически. Для этого в PaidListings используется действие Update Orders. Поэтому при отладке всегда фиксируйте, что именно проверяете: новый заказ после изменения плана или старый заказ, который нужно обновить. Это экономит часы поиска ошибки в шаблоне, когда причина находится в данных заказа.

Перевод существующего каталога на платные категории

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

Как подготовить старые записи

Безопасный путь - создать бесплатный план для категорий, где уже есть записи, назначить ему длительность Never Expires и через действие Create Orders создать заказы для существующих записей. Такой подход даёт каждой старой записи базовый заказ, не требует реальной оплаты и сохраняет доступ к тем полям и медиа, которые должны остаться активными.

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

План миграции без потери доверия

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

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

Продления, cron и проверка срока действия заказов

Платные планы со сроком действия зависят от периодических задач. В документации PaidListings указано, что уведомления об истечении и автоматические истечения заказов обрабатываются через JReviews Cron. Поэтому настройка cron - не техническая мелочь, а часть платной модели. Без неё сайт может принимать заказы, но не вовремя отправлять напоминания или не обрабатывать истечение.

Что делает cron в этой связке

JReviews Cron запускает периодические задачи обслуживания. Для PaidListings это важно из-за expiration notifications и автоматической обработки истёкших заказов. В документации по cron указано, где получить URL: JReviews → Configuration → Cron, как проверить его в браузере и почему после настоящей настройки cron стоит отключить запуск задач при посещениях сайта. Для платного каталога лучше использовать именно серверный cron, а не надеяться на случайные визиты.

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

Когда показывать продление

В PaidListings есть настройка количества дней до истечения, когда пользователь получает уведомление, и этот же параметр влияет на то, когда опция Renewal появляется в Account. Это удобно, потому что пользователь не должен искать продление слишком рано или узнавать о нём уже после истечения плана.

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

Безопасные улучшения и настройки под реальный сайт

Для PaidListings не стоит выдумывать нестандартные хуки и править файлы ядра. Официальная документация уже даёт безопасные точки адаптации: языковые переопределения, настройки уведомлений, поля отслеживания, custom variables планов, доступ к paid-данным в шаблонах и custom lists. Используйте их только там, где есть понятная задача и возможность отката.

Языковые переопределения для понятного checkout-текста

Если пользовательские надписи в публичной части звучат слишком общо, их можно адаптировать через систему языковых переопределений JReviews. Документация объясняет, что add-ons имеют свои language files, но переопределения для JReviews и add-ons можно хранить в одном override-файле. Для Joomla путь переопределения выглядит так: templates/jreviews_overrides/locale/eng/LC_MESSAGES/default.po.

Пример ниже показывает общий принцип. Сначала найдите точный msgid в английском language file PaidListings, затем добавьте только нужную строку в override-файл. Не копируйте весь файл и не редактируйте оригинал add-on.

msgid "Order Summary"
msgstr "Проверьте заказ перед подтверждением"

После создания или изменения override-файла очистите кэш и file registry в админ-панели JReviews, как рекомендует документация. Проверяйте результат на публичной странице заказа. Откат простой: удалите строку из override-файла или верните прежнее значение, затем снова очистите кэш.

Custom variables для аккуратной логики шаблона

PaidListings позволяет задавать custom variables в планах и использовать их в шаблонах или хуках. Документация приводит формат вроде inquiries|1 и метод PaidHelper::getVar. Это полезно, когда нужно показать элемент только владельцам определённого плана, например расширенную форму запроса или блок "премиум-профиль".

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

<?php if (PaidHelper::getVar('inquiries', $listing) == 1): ?>
  <div class="jr-paid-inquiry-note">
    Расширенная форма запроса доступна для этого плана.
  </div>
<?php endif; ?>

Проверка результата: откройте запись с активным планом, где переменная inquiries|1 задана, и запись без этой переменной. Блок должен появляться только в первом случае. Откат: удалите фрагмент из override-шаблона или уберите custom variable из плана и обновите заказы, если переменная должна примениться к уже существующим заказам.

Custom Lists для витрины платных записей

Документация PaidListings показывает, что через Custom Lists можно фильтровать записи по активным plan IDs, используя условие к таблице заказов. Это мощная возможность для страниц вроде "Премиум-компании" или "Выделенные предложения". Но она требует аккуратности: плановые ID отличаются на каждом сайте, а прямой SQL-фильтр должен быть проверен на тестовой копии.

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

Когда PaidListings будет удачным выбором для вашего Joomla-каталога

PaidListings Add-on for JReviews стоит использовать, если каталог уже построен на JReviews, пользователи реально отправляют или обновляют записи, а платная модель привязана к понятной ценности: срок размещения, выделение, расширенные поля, больше медиа, апгрейды и продления. Это не отдельный магазин и не универсальная платёжная кнопка, а слой заказов и планов внутри жизненного цикла записи.

Перед запуском проверьте базовую структуру: категории, типы записей, поля, меню, права, My Account, cron и тестовый обработчик. Затем настройте один простой базовый план, один апгрейд, offline-тест и только после этого подключайте внешние платежи. Если переводите существующие записи, не пропускайте Create Orders и бесплатный план для миграции.

После настройки пройдите путь обычного пользователя от отправки записи до проверки результата. Если все этапы понятны, заказы видны, письма приходят, cron работает, а публичная карточка меняется согласно плану, можно скачать последнюю версию PaidListings Add-on for JReviews и тестировать расширение на своей копии сайта. Лучший запуск - тот, где платная модель не удивляет пользователя, а спокойно объясняет, за что он получает дополнительные возможности.