Settings¶

Review Requests keeps its settings in OpenCart's own setting table, under the module_review_requests group. You set them at Admin > Extensions > Extensions > Modules > Review Requests.

Each key below carries where it applies. per store means a multi-store install can hold a different answer per storefront, and both are honoured: a read takes what that store holds, then what the default store holds, then the shipped default. install-wide means one thing serves every storefront, and the key's own description names that one thing.

Scope¶

Key	Default	What it does
`module_review_requests_status` per store	`0`	Whether the module is enabled. Set by the Status switch on this extension's own settings screen.
`module_review_requests_api_enabled` install-wide	`0`	Whether the extension answers API requests at all. Off, every API route answers `404 api_disabled` in the API's own JSON envelope, so an extension with its API off is shaped like one that has none. Read once for the whole installation from the default store rather than per store, because the credential it checks is OpenCart's own API user, which has no store of its own. It is a separate switch from the module's own Status: an installation may want the requests going out and no API, and — because the two are read independently — the API answers whether or not Status is on, which is deliberate. What happened to a store's own review requests is the merchant's record, and a storefront switch should not hide it.

Requests¶

Key	Default	What it does
`module_review_requests_trigger_status_id` per store	`0`	The order status that means the customer has the goods. Deliberately not Complete's id: `0` means "not chosen", which is what the readiness checklist exists to say, and guessing 5 would arm the extension against a status the merchant never picked.
`module_review_requests_delay_days` per store	`14`	Days between an order reaching the trigger status and the request email. 0 is a legitimate value, for a store whose chosen status already means delivered.
`module_review_requests_reminder_status` per store	`0`	Whether the one reminder is sent. Off by default, which is the market norm rather than a compromise.
`module_review_requests_reminder_days` per store	`7`	Days after the request before the reminder. At most one is ever sent, and any review landing for that order cancels it.
`module_review_requests_backfill_days` per store	`30`	How far back the initial collection window reaches by default.
`module_review_requests_exclude_product` per store	empty	Products never asked about, for the things nobody reviews: gift cards, samples, services. Read when a request or its reminder is sent rather than when the order is found, so a product added here drops out of every request still waiting, and out of a reminder whose request has already gone. An order with nothing else on it is not asked at all. Nothing already reviewed changes. It governs requests only: the verified-purchase badge and Loyalty points are unaffected.
`module_review_requests_exclude_category` per store	empty	Categories never asked about, and every subcategory beneath each one. A product in any excluded category is left out, whichever other categories it is also in. Read when a request or its reminder is sent rather than when the order is found, so it applies to requests already waiting and to reminders whose request has already gone. An order with nothing else on it is not asked at all. Nothing already reviewed changes. It governs requests only: the verified-purchase badge and Loyalty points are unaffected.

Sending¶

Key	Default	What it does
`module_review_requests_cooldown_days` per store	`7`	Days one address is left alone between requests, keyed on the address rather than the customer because guest orders are first-class. 0 means 24 hours, not "no limit": the floor is not configurable.
`module_review_requests_daily_limit` per store	`200`	Emails per rolling 24 hours. A rate rather than a per-pass batch, because how often anything invokes cron.php is the merchant's crontab and the same batch is 50 a day on one store and 1,200 on another.
`module_review_requests_send_from` per store	`0`	The first hour of the day, 0 to 23 on a 24-hour clock, that requests, reminders and an initial collection's emails may go out in. Outside the sending hours passes still run: they find new orders, refresh the review checks and shed old addresses, and send nothing, so what waited goes out in the first pass after the hours open. When this is later than the end hour the window wraps past midnight, so 22 to 6 sends overnight only. When the two are equal there is no window and every hour sends. Read in the installation's one timezone. With a pass every hour, at most 50 emails go out per open hour, so a daily limit above 50 times the number of open hours cannot be reached.
`module_review_requests_send_until` per store	`24`	The hour sending stops at, 1 to 24 on a 24-hour clock, where 24 is midnight: nothing is sent from the start of this hour until the start hour comes round again. Everything the start hour's meaning says about the window applies to it.
`module_review_requests_token_days` per store	`60`	How long a request link keeps opening the review forms. It does not bound the unsubscribe, which is honoured however old the link is.

Retention¶

Key	Default	What it does
`module_review_requests_retention_days` per store	`365`	How long a closed request keeps the customer's address. Retention blanks the address and never deletes the row, because the verified-purchase badge is joined through it.
`module_review_requests_passes_kept` per store	`20`	How many pass records are kept per store, newest first, which is the history behind the Recent passes list and the freshness line above it. A number of rows rather than an age, because a store invoking `cron.php` every minute would otherwise write 1,440 rows a day for a screen that shows the newest ten. The screen still shows ten; raising this keeps more of them behind it.

Surfaces¶

Key	Default	What it does
`module_review_requests_display_status` per store	`1`	Whether the verified-purchase badge and its disclosure line render. One switch for both: turning the badge off retracts the claim, and a disclosure explaining an invisible verification is worse than neither. It does not hide the store's replies to reviews, which are the store speaking rather than a verification claim.

What the customer is told¶

Key	Default	What it does
`module_review_requests_copy` per store	empty	The email and storefront wording, per language code. Read whole to render one email and written whole by one form POST, so it is one setting key holding an array rather than a table. Empty for a language means the shipped language file.

Loyalty¶

Key	Default	What it does
`module_review_requests_review_points` per store	`0`	Loyalty points the author of a review earns when you approve it, through the Loyalty extension's award seam. `0` is off. Paid on approval rather than on submission, because paying on submission pays for spam; paid once per review, so approving it again, or saving it again after an edit, pays nothing. Read from the store the customer's account belongs to. A review collected through a request link earns for the customer account that placed the order. A review with no customer account behind it, such as a guest order's or one you add yourself, earns nothing. With Loyalty not installed this does nothing at all, and the review is approved exactly as before.

Advanced¶

Key	Default	What it does
`module_review_requests_sync_notice_dismissed` per store	`0`	Whether the note about 4.1.x needing the manual Sync button for star averages has been dismissed. Store-wide rather than per user, because "we know about this" is a fact about the store and OpenCart's admin has no per-user preference store.
`module_review_requests_fresh_seconds` per store	`7200`	How old the newest pass may be, in seconds, before the readiness checklist stops believing anything is driving the schedule. It reports; it never stops a send. A store whose own cron runs less often than hourly sets it higher rather than reading an amber line that is telling the truth about nothing — which is the failure a fixed number here produced in `product_feed` and is why this one is not fixed.
`module_review_requests_diary_verbose_until` install-wide	`0`	When detailed logging stops, as a unix timestamp, and `0` is off. Turning Detailed logging on from this extension's settings form stores the moment two days from now; the writer compares that against the clock every time it is asked for a `DEBUG` line, so the window closes on its own with no scheduled task and nothing to clean up. While it is open this extension records what it did in far more detail, and the shared diary consequently holds less history.

What you cannot change, and why¶

These are fixed on purpose. Each one is a decision with a reason beside it rather than a setting nobody got round to adding.

Requests¶

How long a review and its author's name may be is core's own rule, matched here on purpose rather than set here. OpenCart hard-codes these numbers in its own review controller and offers no setting for them under Settings > Option, so a second set here would be a store where the page this extension serves accepts a review core's own page would refuse — and the shopper finds out at the submit. The star scale is core's for the same reason: the column stores one to five.

Rule	Value
Shortest review, in characters	`25`
Longest review, in characters	`1000`
Shortest name, in characters	`3`
Longest name, in characters	`25`
Lowest star	`1`
Highest star	`5`

What the customer is told¶

What the email may say is yours; what it is made of is not. The card list and its cap, the star row, the reason line, and the store's name, logo and postal address are structural and have no wording box. The postal address especially — a review request is a commercial message under 15 U.S.C. 7702(17), config_address is already mandatory and validated in core, and an editable second copy of it is a way to be non-compliant rather than a feature. The disclosure line may be reworded and may not be left blank: UCPD Art. 7(6) makes it material, so a blank is not a state the store may be left in by somebody editing one language.

Sending¶

How much one pass does in one go is fixed, which is the call product_feed makes with Pace: what these conserve is the server's execution time, and a merchant who set the batch above the daily rate would have configured a contradiction no screen could explain back to them. The numbers that are not printed below are a correctness margin — the rows a pass re-reads so a mark moving under it cannot skip an order — the thumbnail size, the number of product cards in the email, and how many asks are swept for closure per pass. None is a judgement a store has a basis to make, and the margin in particular has no answer a merchant could give that would be better than this one.

Rule	Value
Messages one pass may send, whatever the rate allows	`50`

The sending hours are read in the installation's timezone, the one set on the default store's settings, and there is no timezone setting of their own. OpenCart has one timezone per installation: the store form has no timezone field, so every storefront shares that one clock. A second storefront serving customers in another timezone sets its sending hours shifted into the shared one.

How many consecutive send failures end a pass is fixed. The breaker is what makes the one-shot lifecycle safe — nothing retries a failed send, so without it a broken mail configuration would burn the whole backlog's one chance, fifty per pass, silently. Three rather than one, because one timeout is weather. It is not a merchant judgement, and back_in_stock makes the same call about its own.

Rule	Value
Consecutive failures that end a pass	`3`

How long a pass holds its lease before a later one reclaims it is fixed. Fifty SMTP sends at core's default timeout is minutes of legitimate wall clock, so a lease shorter than the work it protects is a second pass joining the first — the one race that loses orders with nothing to show for it, because the mark is what the lease protects.

Rule	Value
A pass's lease, in seconds	`900`

Surfaces¶

Where the badge and the store's reply are spliced into a review list, and the classes they carry, are fixed. The anchor is core's own print of the author rather than the wrapper around it, so a theme that swapped <strong> for something of its own still gets a badge beside wherever it puts the name — and a theme this extension cannot find the anchor in gets no badge rather than a broken page, which the readiness checklist says out loud before a shopper sees it. The classes are Bootstrap 5, which core's default theme ships, so nothing is packaged and nothing is enqueued on a page this extension otherwise only reads.

Rule	Value
The badge is spliced after this print	`/\{\{\sreview\.author\s\}\}/`
The badge's classes	`badge bg-success ms-2`
The disclosure line's classes	`review-requests-disclosure text-muted small`
A reply is spliced after this print	`/\{\{\sreview\.text\s\}\}/`
A reply's classes	`review-requests-reply border-start ps-3 mt-2 small`