Custom Review System for 1C-Bitrix: ORM, Verification, Moderation

Customer reviews are the main conversion factor in an online store. But standard Bitrix solutions (forum, comments component) don't provide the necessary control: no purchase verification, complex moderation, no rating recalculation. We develop a custom review system on ORM D7 — flexible, fast, and

Our competencies:

Frequently Asked Questions

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1455
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    1018
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    879
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    804
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1162

Customer reviews are the main conversion factor in an online store. But standard Bitrix solutions (forum, comments component) don't provide the necessary control: no purchase verification, complex moderation, no rating recalculation. We develop a custom review system on ORM D7 — flexible, fast, and under full control. Over 5 years we have implemented more than 20 such projects for catalogs ranging from 1,000 to 50,000 products. Below are technical details to help you evaluate our approach.

Why ORM instead of infoblock?

Infoblocks are quick to start but hit limitations: complex queries, transactions, and extending the model without migrations are difficult. ORM based on D7 offers flexibility and performance. Our tests showed that SQL queries via DataManager run 2-3 times faster than analogous CIBlockElement::GetList() queries with multiple properties. For a catalog of 10,000 products, the difference in rating output speed reaches 0.5 seconds per page. Additionally, ORM models are easily covered by unit tests, which is critical for large projects.

Criterion Infoblock ORM
Performance Average (properties = additional JOINs) High (flat table)
Flexibility Limited Maximum
Scalability Difficult Easy (adding fields via migrations)
Testing Complicated Easy

Example ORM model

namespace Your\Module\Orm; use Bitrix\Main\Entity; class ProductReviewTable extends Entity\DataManager { public static function getTableName() { return 'b_product_review'; } public static function getMap() { return [ new Entity\IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new Entity\IntegerField('PRODUCT_ID', ['required' => true]), new Entity\IntegerField('USER_ID'), new Entity\StringField('AUTHOR_NAME', ['required' => true]), new Entity\StringField('AUTHOR_EMAIL'), new Entity\IntegerField('RATING', ['required' => true]), new Entity\TextField('ADVANTAGES'), new Entity\TextField('DISADVANTAGES'), new Entity\TextField('COMMENT'), new Entity\EnumField('STATUS', ['values' => ['PENDING', 'APPROVED', 'REJECTED']]), new Entity\DatetimeField('CREATED_AT'), new Entity\BooleanField('IS_VERIFIED_PURCHASE') ]; } } 

This model allows using all D7 features: filters, aggregates, transactions.

Why customize instead of using ready solutions?

The standard forum component is overkill for simple reviews — it brings message trees, access rights, and complex moderation. The comments component lacks purchase verification and calculates rating simplistically. A custom ORM solution gives:

  • Full control over the data schema (adding any fields via migrations).
  • Integration with orders — "Verified purchase" label.
  • Rating recalculation with caching (tagged caching for speed).
  • Flexible anti-spam rules (IP, email, frequency limits).

Comparative tests on a catalog of 5,000 products showed that a custom ORM system loads the product page 0.3–0.5 seconds faster than a forum-based solution.

How does purchase verification work?

One key trust element is the "Verified purchase" label. We check order history via \Bitrix\Sale\OrderTable and \Bitrix\Sale\BasketTable. The code below performs this check:

function isVerifiedPurchase(int $userId, int $productId): bool { $orders = \Bitrix\Sale\OrderTable::getList([ 'filter' => ['=USER_ID' => $userId, '=STATUS_ID' => 'F'], 'select' => ['ID'], ]); $orderIds = array_column(iterator_to_array($orders), 'ID'); if (empty($orderIds)) { return false; } $basket = \Bitrix\Sale\BasketTable::getList([ 'filter' => [ '=ORDER_ID' => $orderIds, '=PRODUCT_ID' => $productId, ], 'select' => ['ID'], 'limit' => 1, ])->fetch(); return (bool)$basket; } 

Status 'F' means completed order. We check exactly that to exclude canceled and unpaid ones. This is standard practice described in the Bitrix documentation.

How is moderation arranged?

New reviews enter the PENDING status. In the admin panel, we create a custom page with a review table and "Approve" / "Reject" buttons. When status changes:

  • APPROVED → review becomes visible on the site, average rating recalculated.
  • REJECTED → review hidden, optionally an email sent to the author.

Notification of a new review for moderator — email event REVIEW_NEW_PENDING, template in Settings → Mail events.

Rating recalculation

After approval or deletion of a review, you need to recalculate the average rating and save it into a product property (e.g., AVERAGE_RATING of numeric type). This speeds up rating display on catalog pages — no JOIN with the review table on each request.

function recalculateProductRating(int $productId): void { $result = \Bitrix\Main\Application::getConnection()->query( "SELECT AVG(RATING) as AVG_RATING, COUNT(*) as CNT FROM b_product_review WHERE PRODUCT_ID = {$productId} AND STATUS = 'APPROVED'" )->fetch(); \CIBlockElement::SetPropertyValuesEx($productId, false, [ 'AVERAGE_RATING' => round((float)$result['AVG_RATING'], 1), 'REVIEW_COUNT' => (int)$result['CNT'], ]); } 

Called from an event handler on review status change.

Anti-spam and restrictions

  • Duplicate review check: one user — one review per product (check by USER_ID + PRODUCT_ID or AUTHOR_EMAIL + PRODUCT_ID for guests).
  • CAPTCHA for guests — standard component bitrix:main.captcha (more on Wikipedia).
  • Rate limiting: one IP cannot send more than 3 reviews per hour (via \Bitrix\Main\Data\Cache or a timestamps table). This measure reduces spam flow by 95%.

All new reviews go through moderation, so even if a spammer bypasses CAPTCHA, the review won't appear on the site without approval.

What's included in turnkey development?

We provide a full package:

  • Documentation on the review API (models, methods, events).
  • Source code with comments and migrations.
  • Instructions for moderators (admin panel).
  • Administrator training (1–2 hours online).
  • 3-month warranty on the program code.

All work is performed by certified 1C-Bitrix specialists with over 5 years of experience. We use tagged caching, agents, and events for maximum performance. Turnkey development reduces moderation labor by 90% and pays for itself within 1–2 months of online store operation.

Development timelines

Scope Composition Timeline
Basic ORM model, form, display, moderation in admin 4–6 days
Full Purchase verification, rating recalculation, notifications, anti-spam, admin section 8–12 days

Exact timelines depend on design requirements and integrations. Get a consultation — we'll prepare an estimate in 1 day. Contact us to discuss your project.