Settings

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

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_wishlist_status per store	1	Whether OpenCart calls a placed "Your wishlist" box, which is the only thing that reads it. Switched on for every store by the install and offered on no screen, because placing the box in Design > Layouts is already the switch.
module_wishlist_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 one thing it serves is OpenCart's own API user, which has no store of its own. It is a separate switch from the extension's own Status, and the two are read independently: the API answers whether or not Status is on, because what shoppers have saved is the merchant's own record and a storefront switch should not hide it.

Retention

Key	Default	What it does
module_wishlist_guest_retention install-wide	180	Days a guest wishlist is kept after its last access before the daily purge removes it and its items. Measured on the guest rather than the item, so an active guest does not lose the thing they saved first. Between 1 and 3650; a number outside that is saved as the nearest one inside it, and there is deliberately no keep them forever — a window with no end is a table that grows for the life of the store. Read once for the whole installation rather than per store, because the one thing it serves is the guest record itself, which carries no storefront: one browser's guest wishlist may hold products from two of your shops, and two retention windows would be two answers about when to delete it.

Alerts

Key	Default	What it does
module_wishlist_price_alert per store	1	Master switch for price-drop alerts. Read per store by the sweep, never from store 0, so a shopfront that has turned these off stays off however the default store is set. Off keeps the flags on the rows rather than clearing them, so switching it back on resumes rather than restarts.
module_wishlist_stock_alert per store	1	Master switch for back-in-stock alerts, read per store by the sweep exactly as the price switch is. A restock fires on the crossing rather than on the level — a product that has been in stock since a shopper saved it never fires — which is what stops the first sweep after an install mailing every customer you have.
module_wishlist_alert_limit install-wide	200	Most customers mailed in one sweep. The rest keep their baselines and go next time, oldest observation first, so nobody starves. Between 1 and 10000. Read once for the whole installation rather than per store, because the one thing it serves is one sweep: it runs under the store's own cron with no storefront of its own, loops every shopfront in turn, and this is the cap on the whole pass rather than on each shop's share of it.
module_wishlist_alert_cooldown per store	86400	How long a saved product may not be mailed about again on the same axis, in seconds. It is per product and per axis rather than per customer, so a price oscillating across a threshold cannot mail hourly, and it never delays a genuine restock — one restock can only fire once, because notifying resets the baseline to what was notified. Between 3600 and 1209600. Per store, read alongside the two master switches by the sweep, so a shop with daily price changes can batch where a quieter one tells people at once.
module_wishlist_alert_cycle install-wide	empty	How often the alert sweep actually runs: hourly, daily, weekly or monthly, or empty for every time the store's cron wakes it — which is hourly, and is what it did before this setting existed. The registered cron row stays hourly whatever you pick, because that row is the wake-up rather than the schedule; this is what the sweep asks before it does anything. A store whose prices move on a nightly import would rather send one mail a day than one an hour, and this and the cap above are the two halves of how much mail a sweep can produce. Read once for the whole installation rather than per store, because the one thing it serves is that single cron row.

Wording

Key	Default	What it does
module_wishlist_copy per store	empty	The wording a merchant may write in their own words, per language code: the shared list's heading, the alert email's greeting, and its unsubscribe line. Read whole to render one email and written whole by one form POST, so it is one key holding an array rather than a table. A language absent from it, or a field left blank, is the wording the extension ships. Per store, because it is read on a storefront page and in a mail sent on a storefront's behalf.

Layout module

Key	Default	What it does
module_wishlist_module_limit install-wide	4	How many saved products the "Your wishlist" layout module shows wherever you place it, from 1 to 12: the shopper's own most recent saves in this store, newest first. One number for every placement, because the module is single-instance and OpenCart keeps no per-placement settings for it. Install-wide because a placement is a row of OpenCart's own layout table, which has no storefront column. Placing the module is done at Design > Layouts, and until it is placed this number does nothing. An update removes the module from every layout, because OpenCart's own uninstall deletes every placement of a module along with it: place it again after updating. The number itself is kept.

Reports

Key	Default	What it does
report_wishlist_status install-wide	1	Whether Most Wishlisted is offered under Reports > Reports. Kept under the report_wishlist code rather than this module's own, because OpenCart deletes a report's settings when the report alone is uninstalled and the module's must not go with them. Read once for the whole installation rather than per store: the one thing it serves is the admin's own Reports dropdown, which no storefront has a copy of.
report_wishlist_sort_order install-wide	0	Where that report sits in the Reports dropdown, among every other report the store has. Under the report_wishlist code for the same reason, and install-wide for the same reason.

Advanced

Key	Default	What it does
module_wishlist_sweep_secret install-wide	empty	The shared secret the alert sweep and the nightly purge are compared against when either is called over the web, generated at install. It is what a merchant with no shell pastes into a host's cron panel or a third-party cron service, and it matters most on the OpenCart release whose own scheduler cannot run at all. One secret for both scheduled rows, because both addresses are printed on the same screen to the same person and a second one would be a second thing to rotate for no difference in what holding it lets somebody do. Rotating is its only control: there is no free-text edit, because a secret a merchant can type is a secret a merchant can shorten. An empty one refuses every call rather than admitting every call. It is remembered across an update on Rotate's own argument — rotating stops a cron line that was working until it is re-pasted, which is why that button confirms and says so, and a control that needs a confirm dialog is a control an update must not operate. An uninstall does not take it: an update is an uninstall and an install, so the remembered copy puts it back, and Rotate is the one way to revoke it. It is not the key unsubscribe links are signed with, which is a different value with a different lifetime and no button at all. Read once for the whole installation rather than per store, because the one thing it serves is a pass that loops every shopfront and belongs to none of them.
module_wishlist_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.

Alerts

One value lives in Wishlist's own table rather than in OpenCart's, and it is not a setting you can see or edit: the key every unsubscribe link is signed with. It is generated once, on the first install, and is never regenerated — a new one would silently break every unsubscribe link the store has ever sent, and those sit in inboxes for years. There is no rotate button for the same reason there is no edit field.

Retention

How long a guest's cookie token, a share link's token and an unsubscribe link's token are is fixed. They are what stops one shopper guessing another's list, and a merchant shortening one would be weakening a guarantee they cannot see the effect of. They are the same length on purpose: three different numbers would be three different guarantees to explain.

Rule	Value
Characters in a guest token	32
Characters in a share token	32
Characters in an unsubscribe token	32

How many expired guest wishlists one nightly purge removes is fixed. It is a bound on one run rather than a policy: the first purge on a store with years of guests behind it leaves its remainder for tomorrow instead of trying to finish inside one request, and nothing is kept any longer for it — the cut-off is the retention window above, which is yours.

Rule	Value
Guest wishlists removed in one nightly pass	500