JLex Review - Joomla Extension

A Practical Guide to Configuring and Using JLex Review on a Joomla Website

JLex Review is a Joomla extension for review pages, ratings, and user comments. This guide focuses on real-world use rather than marketing copy: how to prepare your site, install the component, publish a review page through a menu item or module, configure the form, moderation, anti-spam protection, notifications, structured data, and result validation.

This material is especially useful if you want to turn reviews into a managed system: collect ratings across multiple criteria, let users attach supporting materials, moderate submissions, import older reviews, display ratings in the right place on the site, and keep content quality under control. In Joomla, that matters because the final result depends not only on the component itself, but also on the menu item, modules, template, cache, user permissions, and any connected integrations.

Below you will find detailed post-install configuration, a real scenario for a product or service page, troubleshooting for common issues, a comparison with similar solutions, and an FAQ. The images in this article are educational diagrams and interface mockups inspired by official screens and demos, not direct screenshots of third-party pages.

What the Extension Actually Solves and Where It Fits Best

The main purpose of JLex Review is to give a Joomla site its own review and rating system that can be embedded into different types of content. According to the official documentation, the product supports a standalone review page, module output for page builders, and add-on-based integrations with other extensions. That makes it more than a simple feedback form - it becomes a separate layer of user-generated content: a visitor leaves a rating, the administrator controls publication, and the site displays the aggregated score, the review list, comments, and additional data.

A typical use case is a service page, product page, catalog entry, real estate listing, event page, or a K2 item or Joomla Article where you need more than a single static testimonial. JLex Review makes sense when you want to store reviews inside Joomla, manage them from the admin panel, and tie them to a specific site item. If all you need is to display existing reviews from Google Business Profile or Facebook without your own form, that is a different scenario: an external review widget may be simpler, but it does not replace a full local moderation system and submission form.

It is also important to understand the difference between "reviews on a page" and "a review-driven directory." JLex Review can handle a review page, reviews attached to content, and add-on integrations with components. But if you are building a large directory with listings, owner claims, advanced faceted filtering, and its own business logic, it may be worth comparing it to JReviews. That does not make JLex Review weaker - the two products simply have a different center of gravity.

Who This Product Is a Good Fit For

This extension is especially appropriate for sites where reviews should be part of the Joomla structure rather than an external widget. That may include service directories, local business websites, educational projects, product catalogs on VirtueMart or HikaShop, multilingual sites, content portals, and pages with user ratings. A basic understanding of Joomla is helpful: where components, menu items, modules, plugins, access permissions, and cache clearing are managed.

• For a site owner, JLex Review makes it possible to collect reviews without relying on an external platform and monitor them from the admin panel.
• For a content manager, the product provides a form, moderation tools, filters, and review publishing by page.
• For a webmaster, the key value is in the add-ons, module, template override, custom CSS, and the ability to connect reviews to Joomla components.
• For a developer, synchronization features, templates, and integration scenarios can be useful, but they should be used carefully and according to the documentation.

When JLex Review May Not Be the Right Starting Point

You probably should not install this extension just to show one static testimonial on the homepage. A regular module or a template block is enough for that. JLex Review can also be excessive if the site does not plan to accept visitor reviews at all, does not need ratings, and has no intention of moderating user-generated content. Another important case is a complex marketplace or directory project where, in addition to reviews, you need listings, paid profiles, owner claims, advanced search, and separate user dashboards. In that case, compare your requirements with the capabilities of dedicated directory components first.

Practical rule of thumb: choose JLex Review if the central task is adding reviews and ratings to existing Joomla pages. If the central task is building the entire directory itself, reviews will be just one module in the future architecture.

How JLex Review Is Structured: Component, Module, Add-ons, and Public Output

To avoid getting lost in the settings, it helps to think of the product as several connected parts. The component stores review entities, forms, elements, moderation settings, notifications, and permissions. The module lets you display part of the functionality in template positions or inside pages built with a page builder. Add-ons are used to connect the system to specific third-party extensions: Joomla Content, K2, VirtueMart, HikaShop, JoomShopping, Community Builder, EasySocial, EasyBlog, DJ-Classifieds, Zoo, FLEXIcontent, Cobalt, SobiPro, and other systems listed by the developer.

This structure explains many common mistakes. A user may install the main package and expect reviews to appear automatically inside every product or article. In practice, you need to choose the output method: a standalone menu item, a module with a dynamic source, or an integration add-on for the target component. If the wrong method is selected, the extension may be installed correctly, but the form will not appear on the public page where you expected it.

Standalone Review Page

The easiest way to start is to create a menu item of type JLex Review > Review Page. That opens a separate page where reviews can be submitted and displayed. It works well for a "Customer Reviews" page, a service overview page, a general review showcase, or a test launch on a site copy. This route is also useful for troubleshooting: if the standalone page works but the integration with a product or article does not, the issue is usually not the component itself, but the output method, add-on, template, or dynamic source.

Module for a Page, Page Builder, or Template Position

The official documentation describes a dedicated JLex Review module. It can display a review page, new reviews, top-rated items, or statistics. For pages built in a Page Builder, the module is especially important: you can set Item Source to Dynamic Item and specify both the extension name and the dynamic variable. That allows one module to be reused across different pages where the specific object is determined from the page context.

In this scenario, it is critical not to blur two separate layers. A module does not automatically "guess" any page on its own. You have to tell it where the item comes from. If the page is built in a non-standard way, if the alias or id changes, or if the builder passes data differently than JLex Review expects, the dynamic link may require developer support or a dedicated integration.

Add-ons for Integration with Other Extensions

Add-ons are the practical backbone of the JLex Review ecosystem. The developer's site lists extensions for AdsManager, Joomla Article, K2, VirtueMart, iCagenda, jDownloads, Community Builder, DJ-Classifieds, EasyBlog, EasySocial, J2Store, JEvents, JoomShopping, OS Property, SobiPro, Zoo, and other products. For a site owner, the implication is simple: first determine exactly where reviews should appear, then check whether an add-on exists for that component.

If an add-on exists, install it through the standard Joomla installer and check which plugins or modules it added. If there is no add-on, do not try to paste arbitrary short code into any page field and expect it to work. JLex Review does include developer-oriented features such as replacer and synchronization, but they require an understanding of PHP and object structure. For a standard site, it is safer to rely on the documentation or support than to invent integration code.

What to Check Before Installation and First Launch

Preparation is not just a formality. The extension works with user input, media, notifications, structured data, and integrations. A mistake at this stage may not show up immediately: reviews fail to submit, a file does not upload, the captcha does not appear, rich snippets do not make it into the markup, the module does not show in the right position, or visitors keep seeing stale content after cache is enabled.

Joomla Compatibility and Server Requirements

The developer's documentation lists support for Joomla 3 through 6, but it also notes separately that Joomla 3 is no longer supported by the standard package and requires a separate installation archive from the developer. For a new site, it is best to plan around a current Joomla branch. If the site is older, first verify template, PHP, third-party component, and add-on compatibility before installing a review system.

For PHP requirements, the documentation mentions ZIP Library, GD Library, and either cURL or enabled allow_url_fopen. That is not a random checklist. ZIP is needed for package installation, GD for image handling, and cURL or URL file access for network operations that integrations and external services may require. You can check these settings in System - System Information - PHP Information.

Backup and Staging Environment

JLex Review creates its own tables and may add plugins, modules, and integrations. Before installing it on a live site, back up both files and the database. For a commercial site, it is more sensible to test the extension on a staging copy: there you can enable moderation, submit a test review, check the template, cache, notifications, and integration with the target component without putting visitors at risk.

If the site already uses an older review component, make the migration decision in advance. The JLex Review documentation mentions CSV import and migrators from HikaShop, VirtueMart, JComment, and Komento. But import applies to one item at a time, and bulk export across all pages is not supported because forms differ. That is why review migration should be tested on a small dataset first: one page, one form type, one expected result.

Permissions and the User Flow

Before installation, it helps to answer four questions: who will be allowed to leave a review, whether login is required, whether moderation is needed, and whether guests may attach files or provide an email. In JLex Review, permissions are split between users and administrators. Actions such as writing, editing, and deleting reviews, uploading media, voting, reporting, subscribing, auto-publishing, and viewing hidden content are configured separately. That is one of the reasons this extension should not be configured by guesswork.

Safe starting point: for the first launch, enable moderation, restrict file uploads, and test notifications. After the test, you can gradually expand permissions - not the other way around.

Installation, Menu Item, and the First On-Site Validation

JLex Review is installed through Joomla's standard extension workflow. Download the archive from the developer, open System - Install - Extensions, select the package, and run the installation. If the package includes the component, modules, and plugins, then after installation check not only the component menu, but also the module and plugin lists. Joomla documentation explicitly reminds you that modules and plugins must be enabled, otherwise they may be installed but still not function on the site.

After installation, do not jump straight into integrating with VirtueMart, HikaShop, or a Page Builder. Start with a simple standalone page. This is your checkpoint: it confirms that the main component is installed, the menu item works, the template renders the page, the form is visible, and review submission is not blocked by an obvious issue.

Checkpoint Menu Item

1. Open Menus - the target menu - New.
2. In Menu Item Type, select JLex Review - Review Page.
3. Set a clear title and alias, for example for a company or service review page.
4. Save the menu item and open it on the public side of the site.
5. Verify that the rating block, review list, or form is displayed according to your initial settings.

If the menu item opens but the form is not visible, check permissions, moderation, guest access, and the review form itself. If the page does not open at all, enable Joomla debugging only on a test copy and review the error log. If the problem appears only with the site's template, temporarily switch to a default Joomla template and compare the result.

First Test Review

For the first test, use a separate regular user account rather than a super user account. That lets you see the extension the way a visitor sees it. Submit a short review, assign a rating, fill in any extra fields that are already enabled, and observe what happens after saving. With moderation enabled, the review should not become publicly visible right away. In the admin panel, it should appear in the queue of entries awaiting publication.

The short post-install summary is simple: you should have a working page, a clear route in the menu, a test review in the admin panel, and predictable publication behavior. Until that is confirmed, do not move on to complex add-ons and rich snippets.

Configuring the Form, Rating Criteria, and Review Fields

The review form is one of the main working tools in JLex Review. In the documentation it is called Review Form, and in older versions it may appear as Section File. The basic form includes a title, rating, and review text. Additional field types include checkbox, select, text, textarea, and score. That makes it possible to collect more than just "five stars and a comment" - you can gather structured feedback such as quality, service, ease of use, delivery, product condition, experience category, visitor type, or any other criterion that matters for your specific site.

The key here is not to overload the form. The more fields you add, the less likely a typical visitor is to complete the submission. For an initial launch, a short structure is enough: overall rating, two or three rating criteria, and one text block. Only enable extra fields where you will actually use the result - for filtering reviews, showing a rating breakdown, analyzing complaints, or moderating disputed submissions.

A Basic Form for Most Sites

Open JLex Review - Configuration - Review Form. Create or edit the form, then arrange the fields in the order users naturally make decisions. Start with the overall rating, then a short title, then the review text, followed by any clarifying fields. If you use multi-factor rating, give each criterion a clear label. Do not name criteria too vaguely: "Quality," "Service," and "Price" are much more useful than "Parameter 1" and "Parameter 2."

For a multilingual site, check in advance how field labels will be translated. If the extension already includes the needed language strings, use them. If the text needs to be adapted for a Russian-language site, it is safer to use Joomla language overrides instead of editing the extension files. That approach survives updates and does not break the package.

Different Forms for Different Pages

The documentation states that you can change the form for a specific page through JLex Review - Items - target item - Review Form. That is useful if product reviews need criteria like "quality," "shipping," and "packaging," while event reviews need "organization," "location," and "program." But changing the form on a page that already has reviews must be done carefully: if the new form differs too much from the old one, the displayed data may become inaccurate or incomplete.

A safe workflow looks like this: first create a new form, apply it to a test item, submit several sample reviews, check the public output and export, and only then roll the form out to the live page. If older reviews do not contain values for the new fields, do not expect a clean retrospective statistics layer.

Rating without Review and Short Ratings

The ability to leave a rating without a full text review is useful if you want to lower the participation barrier. But it changes the quality of the data: you get more ratings and fewer explanations. For services, healthcare, education, expensive products, and sensitive topics, it is usually better to require at least a short text so the administrator understands the reason behind the score. For simple catalogs, voting flows, or quick reactions, a text-free rating may be appropriate.

How to Test the Form After Saving

Open the page in a private browser window, submit a review as a guest or regular user, then check the admin panel. If a field is required, the form should clearly enforce it. If files or images are enabled, test not only the upload itself but also whether they appear in the review list. If moderation is enabled, make sure the visitor cannot see an unapproved review as if it were publicly available.

Moderation, Anti-Spam Protection, and Notifications Without Admin Chaos

Reviews are user-generated content, which means spam, disputed scores, complaints, duplicates, emotional comments, and attempts to attach unnecessary materials come along with the benefits. JLex Review offers several layers of control: captcha, blacklist, reporting system, publishing permissions, and notifications. Strong configuration is not about turning on everything at once - it is about choosing a mode that matches the site's risk level.

Publication Moderation

For a new project, enable manual publishing of reviews and comments. In the documentation, this is configured through Configuration - Permission: disable auto-publishing for the relevant user groups. That way, the review is visible to the administrator and the author, but it does not become public until it has been checked. This mode is especially important for sites with public profiles, local businesses, products, medical services, or legal services.

Once the review flow becomes predictable, you can split the rules. For example, you may allow faster publication for registered repeat customers while keeping guest reviews under moderation. But that should only be done after you have observed the quality of incoming submissions.

Captcha and Blacklist

JLex Review supports Joomla Captcha as well as dedicated captcha plugins provided through add-ons. If your site already uses the standard Joomla Captcha, start there: it means fewer dependencies and easier troubleshooting. The setting is located in Configuration - Restriction - Joomla Captcha. If spam still gets through, review the developer's add-ons and check which plugin is compatible with your Joomla version and template.

The blacklist blocks a user or guest by IP. Use it for repeat offenders, but do not make it your primary line of defense. An IP address may be shared by multiple visitors, and aggressive blocking can accidentally cut off legitimate users. A healthier setup is: captcha, moderation, upload restrictions, clear form rules, and then blacklist for obvious repeat abuse.

Notifications and Cronjob

Admin notifications help you avoid missing new reviews, comments, and reports. In JLex Review, you can choose immediate delivery or cronjob mode. Immediate delivery is simpler, but if many events occur it can put unnecessary load on mail sending. Cronjob mode shifts processing to the hosting scheduler, but it requires you to add the command shown under Configuration - Notification - Cron Job Command.

If you enable email notifications, make sure to submit a test review and verify delivery to a real address. If the email never arrives, the issue may not be JLex Review at all - it may be the Joomla mail configuration, SMTP, SPF/DKIM, hosting limits, or the recipient's spam filtering. Do not start by changing every component setting at once. First confirm that Joomla's system mail is working.

Integrations, Modules, and Displaying Reviews Inside Joomla Pages

The most interesting part of JLex Review begins when reviews become part of a specific page. That page may be a VirtueMart product, a Joomla article, a K2 item, a directory listing, a user profile, a Page Builder page, or a separate block in a template position. In every case, the item source matters: the extension has to understand which object the review belongs to.

Displaying Reviews Through a Module and Dynamic Item

For page builders, the documentation recommends the JLex Review module. In the module settings, you choose the function Create a review page, set Item Source to Dynamic Item, and then define Extension Name and Dynamic Variable Name. The documentation uses examples such as sppagebuilder and yootheme for extension names. The variable is often id, but the exact value depends on how the page passes the object.

Do not enter the extension name with spaces, hyphens, or arbitrary capitalization. The documentation limits the value to the characters a-z, 0-9, and _. If the name looks nice but is technically wrong, the module may fail to find the object. After saving, test two different pages with different ids: reviews should attach to each page separately rather than being merged into one shared list.

Reviews for Products and Catalogs

For VirtueMart, HikaShop, JoomShopping, and similar components, start by checking the add-ons. Installing the main package does not guarantee automatic attachment to a product page. After installing the add-on, review the plugin list: the required plugin may need to be enabled manually. Then open one test product page, submit a review, check whether an item appears in JLex Review - Items, and confirm that the link points back to the correct page.

If the product has been renamed, its alias changed, or it was moved to another category, JLex Review may require title and URL synchronization. The documentation includes a Title & Link Source section and a developer scenario called Synchronization, but automatic options are not supported for every extension. For an uncommon or custom component, it is better to confirm with the developer in advance whether a ready-made connection exists.

Module Positions Inside the Review Block

The documentation lists positions such as jr-top, jr-before-list, and jr-after-list, where you can insert additional modules. This is useful for a note before the form, a rules block, a link to the review policy, a support banner, or extra navigation. Use these positions sparingly: the review page should not turn into a promotional landing page where the user loses sight of the form.

Rich Snippets, Structured Data, and Result Validation

JLex Review supports structured data in JSON-LD format and can output the average rating and review count for pages where reviews are integrated. That does not guarantee an enhanced search result. Search engines decide for themselves whether to show ratings and take into account the page type, data quality, schema.org compliance, review markup guidelines, and overall site trust. But technically correct markup is the required foundation.

When to Enable Rich Snippets

It makes sense to enable markup where reviews genuinely belong to a specific object: a product, service, organization, event, software product, or any page with a clearly defined subject of evaluation. If a page contains a general list of unrelated reviews about the site as a whole, an aggregated rating may be questionable. The JLex Review documentation mentions types such as LocalBusiness, Event, Organization, SoftwareApplication, and a reference to schema.org. Choose the type carefully and do not apply schema just for cosmetic reasons.

The setting is located in Configuration - General - Rich Snippets. If the page already uses Microdata and you only need to add aggregateRating, the documentation describes an Only Average Rating mode under Configuration - Advanced. That is an important detail: two competing markup systems on the same page can produce an unclear result.

How to Validate the Markup

1. Open a public page that already contains a published review and rating.
2. Check the source code or use a structured data validation tool.
3. Make sure the rating belongs to the correct object, not to some unrelated block on the page.
4. Check whether the template or another SEO component is outputting the same aggregateRating a second time.
5. Clear Joomla cache and template cache if changes are not visible right away.

If rich snippets do not appear in search, that does not automatically mean the extension is broken. First verify that JSON-LD is present on the page and that there are no conflicts. Then review search engine rules and page quality. JLexArt support has public discussions about rich snippets, which shows this is a real user concern, but the solution depends on the page, the template, and the markup generated by other extensions.

Practical Scenario: Reviews for a Service or Product Page

Let us walk through a working scenario that can be adapted for a service, product, directory item, or course page. The goal is to display a review block, collect a rating across multiple criteria, enable moderation, validate the public result, and prepare basic troubleshooting. This example is not tied to purchasing a license or handling payment. We assume the administrator already has the extension archive and the required add-on.

Goal and Preparation

You want a page where the visitor sees the average rating, a list of published reviews, filtering or sorting options, a submission form, and predictable behavior after publication. Before you begin, you should have a Joomla site, JLex Review installed, a test user, either a menu item or a product page, a backup, and a clear understanding of how reviews will be displayed: through a standalone page, a module, or an add-on.

Setup Steps

1. Create a checkpoint page through the JLex Review - Review Page menu item and confirm that the component opens correctly.
2. Configure the form in Configuration - Review Form: overall rating, title, text, and two or three rating criteria.
3. Enable moderation in Configuration - Permission by disabling auto-publishing for guest or all reviews.
4. Enable Joomla Captcha or a suitable captcha add-on if the site accepts guest reviews.
5. Configure administrator notifications and submit a test review.
6. If the page should be embedded inside a product or article, install the appropriate add-on and verify item binding.
7. Clear cache and test the public page in a private browser window.

Expected Result

After you submit the test review, a new entry awaiting moderation should appear in the admin panel. If the review is published, the public page should display the rating, the review list, and the selected fields. If structured data is enabled, the page source should contain JSON-LD markup that matches the page type. If modules are used inside jr-top, jr-before-list, or jr-after-list, they should appear in the expected location and not break the form.

A Common Detail That Causes Problems

The most common mistake in this scenario is testing the result as an administrator and assuming that behavior applies to everyone. An administrator may see hidden elements, unapproved reviews, and extra actions. That is why at least two checks are mandatory: the public page as a guest and the same page as a regular registered user. If the results differ, inspect permissions, user groups, moderation, publication status, and cache settings.

Practical Ways to Use JLex Review on Different Types of Sites

JLex Review has enough functionality to be used for more than simply "putting stars under a page." Below are several scenarios based on documented capabilities: multiple forms, rating criteria, integrations, the module, import, notifications, user profiles, ratings, subscriptions, and review filtering.

Reviews for Local Business Services

For a salon, clinic, service provider, school, or agency, create separate service pages and attach reviews to each one. Keep two or three criteria in the form: service quality, communication, timing, or convenience. Moderation is essential here: reviews may contain personal data, conflict-sensitive wording, or complaints that need to be handled carefully. The result check is straightforward - open each service page and make sure reviews are not being mixed across services.

Product Ratings in a Joomla Store

For VirtueMart, HikaShop, JoomShopping, or J2Store, start with the official add-on if one is available. In the form, include criteria that genuinely help the buyer: quality, match to description, shipping, packaging. Do not enable too many fields, or customers will leave only an overall rating or skip the review altogether. After testing, make sure the review is linked to the correct product and that the admin-panel link leads to the current product page.

Reviews for Articles, Courses, or a Content Library

On a content site, reviews can serve as an expanded comment system with ratings. For example, a reader may rate an article, course, book, video lesson, or event. Filters, subscriptions, and notifications are especially useful here: the author or administrator can see audience response, while other users can judge content by its ratings. If the site is multilingual, enable Language Filter and confirm that reviews are shown in the correct language.

Ranking Active Users

JLex Review can display user profiles and a ranking page. This is useful for communities where participant activity matters: expert reviews, comments, helpful ratings, or answers to other users. But before enabling that scenario, think through the rules: what drives visibility, which actions are moderated, whether helpfulness can be gamed, and how the administrator will respond to complaints.

Safe Enhancements: Styling, Language, and Template Changes Without Editing the Core

JLex Review includes template settings, custom CSS, and custom JavaScript, and it also supports template override. That gives you room for careful adaptation, but it is important not to edit Joomla core files, component files, or the installed template directly. Any update may overwrite those changes.

Small CSS Tweak Through the Component Settings

If you need to visually separate an unapproved review, the form block, or the submit button, start with custom CSS in Configuration - Advanced. The exact classes are best checked in your page HTML because they may depend on the selected template package. The example below shows the general approach, not a promise that the same class exists in every version. Use it only after verifying the selectors in your browser inspector.

/* Example of a safe local tweak: apply only after checking the classes on your page */
.com-jlexreview .jr-review-form {
  border: 1px solid #d9e2ef;
  border-radius: 8px;
  padding: 18px;
  background: #f8fbff;
}

.com-jlexreview .jr-review-form .btn,
.com-jlexreview .jr-review-form button {
  min-height: 42px;
}

Validation is simple: save the CSS, clear Joomla cache and template cache, and open the page in a private window. If the style does not apply, do not start adding !important everywhere. First check the actual wrapper class, CSS load order, and the selected template package. Rollback is equally simple - remove the added CSS from the extension field and clear the cache again.

Language Overrides Instead of Editing Files

If you need to change a button label, field hint, or error message, use Joomla's built-in language overrides. In modern Joomla versions, this is done through system language overrides: find the string by its visible text, create an override for the target language and site client, and save it. This method is better than manually editing the extension's .ini files because an update will not wipe out your change.

Template Override for Deep Output Changes

The JLex Review documentation describes sub-templates and copying component templates into the site's template directory. That is already a task for a developer or an experienced webmaster. Before creating an override, back up the template, document the list of changed files, and test updates on staging. If the task is only about color, spacing, or button size, CSS is almost always safer than rewriting the output template.

Permissions, Moderation Rules, and Review Policy

JLex Review gives the administrator many legal and editorial control points: who can write a review, who can edit it, who can delete it, who can upload media, who can view hidden content, who can publish comments, who can subscribe to a page, and who can submit a report. If these rules are not defined in advance, a review system quickly turns into a conflict between the visitor, the manager, and the administrator. That is why before a public launch, you should create not only the settings but also a short internal policy.

The policy is not bureaucracy - it is consistency. One moderator should not publish emotional reviews containing personal data while another deletes identical reviews without a trace. One manager should not reply privately while another is already publishing a comment on the site. For a small project, one document is enough: which reviews are published, which are returned for clarification, which are deleted, who responds to complaints, and how quickly the administrator reviews new submissions.

Minimum Permission Model to Start With

For the first launch, do not give guests the maximum possible capabilities. A guest may be allowed to leave a review if that matters for conversion, but file uploads, auto-publishing, and advanced editing are better kept restricted. A registered user can receive more permissions if the site genuinely uses accounts. The administrator should see email, IP, and hidden content only within their actual working role, because that data relates to visitor privacy.

• Guests: Review submission through the form, captcha, mandatory moderation, minimal field set.
• Registered users: Reviews, comments, subscriptions, notifications, and editing their own content if allowed by site policy.
• Moderators: Publishing, unpublishing, complaint handling, and access to internal data only when necessary.
• Administrators: Form, permission, add-on, notification, template override, and integration configuration.

You can refine this model over time, but it is safer to start here than to immediately allow everything for every group. After a week or two of test collection, you will see where restrictions are unnecessarily blocking users and where they are protecting you from spam and chaos.

Terms of Use and Consent Before Submission

JLex Review includes Terms of Use among its feature set. This is a useful element for a public form, especially if the site collects reviews about people, medical services, education, real estate, delivery, or expensive products. The policy text should not be a long legal wall directly inside the form. It is better to create a separate page with publication rules and place a short consent phrase next to the checkbox.

The policy should explain four things: the review must reflect real experience, personal data of third parties must not be published, the administrator may refuse to publish spam or abusive content, and disputed issues are handled through a contact channel. This does not replace legal advice, but it helps users understand the boundaries. A clear policy reduces moderation load because disputed decisions can be explained by linking to published rules.

How to Organize the Review Queue

For a small site, checking new reviews once or twice a day is usually enough. For a store or service business with active sales, it is better to tie review checks into the support workflow. The administrator receives a notification, opens the queue, checks the text, attachments, rating, item page, and user history. If the review is acceptable, it gets published. If it reflects a customer issue, it should first be escalated to the manager, and only then either a response or the review itself is published, depending on site policy.

Do not delete a negative review just because it lowers the average rating. What should be removed is spam, abuse, personal data, duplicates, and off-topic messages. A negative but specific review is often better handled than removed: it shows the system is real and helps uncover actual problems. If you publish only perfect scores, visitors will quickly stop trusting the review block.

Final Check Before Opening the Form

Before publishing the form on the live site, walk through a short checklist: the guest can see the rules, the form does not ask for unnecessary fields, captcha works, an unapproved review is not visible to everyone, the moderator receives a notification, reporting is available only to the right groups, attached files do not expose private data, and a regular user cannot see administrative actions. If even one of these points has not been checked, it is better to delay launch until it is fixed.

Import, Export, and Migration of Older Reviews

If the site has collected reviews before, data migration may matter more than appearance. JLex Review supports CSV import and migration from several extensions: HikaShop, VirtueMart, JComment, and Komento. For CSV, the minimum required fields are creation date in YYYY-MM-DD HH:MM:SS format, review text, and author name. After preparation, the file is uploaded through JLex Review - Import & Migration.

The main limitation is that one import applies to one page. That prevents chaos, but it requires careful preparation if there are many old reviews tied to different products or content items. Do not put the entire archive into one CSV if the reviews need to be distributed across different items. Start with a test: one item, 5-10 rows, different ratings, one long review, and one review with less-than-perfect characters. After import, check the public output and export the data back out.

How Not to Lose the Meaning of Older Data

Before migration, compare the old form with the new one. If the old component had fields such as "Pros," "Cons," and "Usage Experience," while the new form only includes a general text field, part of the structure will be lost. If the new form is richer than the old one, older reviews will simply have no values for the new fields. That is normal, but you need to understand it before publishing. For important catalogs, keep the original CSV as an archive and document how each column was mapped.

When Migration Is Better Done Manually

If the old component is heavily customized, if the database contains HTML markup, custom fields, non-standard ids, or mixed languages, automatic migration may produce unexpected results. In that case, it is safer to prepare a cleaned CSV, import one item, review the result, and only then repeat the process. If the dataset is large, run the migration on a site copy and document the steps so the process can be repeated on the live version.

When JLex Review Is the Right Choice

JLex Review is a strong option if you need a managed review system inside Joomla: forms with criteria, moderation, anti-spam tools, notifications, structured data, component integrations, and the ability to display reviews through a menu item or module. It is not the lightest option for a single static testimonial, but it is a strong tool for a site where reviews become part of the content, trust layer, and navigation.

Before rolling it out in production, follow a short validation path: install the package on a site copy, create a menu item, configure the form, enable moderation, submit a test review, validate the public output, and only then add the required add-on or module. If everything works in the simple scenario, you can move on to products, services, integrations, imports, and rich snippets.

If the product fits your use case after validation, you can go to the JLex Review download and test it on a prepared site copy. That order reduces risk: first a clear goal and validation plan, then installation, then configuration, and only after that reviews on live pages.