Skip to content

Requirements and install

Back In Stock installs like every other extension sold here. Follow the shared procedure rather than a Back In Stock-specific one:

What is specific to Back In Stock

A fresh install is inert. Uploading the archive puts the files on the server and nothing else: no form appears on any product page, no email is ever sent, and the admin screens are not reachable. Two more things have to happen, and they are the two steps most often skipped.

Enabling the module is what creates everything. Under Extensions → Extensions → Modules → Back In Stock, the extension list's own + button creates the six tables, the settings, the scheduled sweep, the demand report and the events that put the capture form on your product pages. Then open the module itself and set Status to Enabled and save. Off is off everywhere: no capture form is offered and nothing is sent.

Three permission entries to tick, not one. Under System → Users → User Groups, tick each of these under both Access Permission and Modify Permission, for every group that should be allowed to use Back In Stock:

extension/back_in_stock/module/back_in_stock
extension/back_in_stock/catalog/back_in_stock
extension/back_in_stock/report/back_in_stock

They are separate on purpose. The first is the settings screen. The second is Catalog → Back In Stock, which shows email addresses and is where erasure and suppression requests are honoured. The third is the demand report, which shows numbers and no addresses, so you can hand somebody the demand figures without handing them the mailing list. The group that installed the extension is granted all three automatically; every other group is granted them here.

Two more for the data-protection screens, also granted to the installing group automatically:

extension/back_in_stock/customer/personal_data
extension/back_in_stock/customer/purge

The first opens Customers → Personal Data and needs Access Permission only; acting on it also needs OpenCart's own Modify Permission on customer/customer. The second is the screen that removes everything Back In Stock holds about everybody, and needs both. They are separate so that you can give somebody the one-person screen without giving them the one that empties the lot.

Alerts need something to call the sweep. A shopper viewing a page sends nothing. A product save in the admin sends the first batch for that product at once, and every batch after it waits for the sweep. The settings screen lists the three ways of waking the sweep, with the exact crontab line for each and your own store's address already filled in (see keeping the sweep running). Any one of them is enough.

On OpenCart 4.1.0.4, use the web address or the command line. That release cannot run any scheduled task at all: its cron.php fails inside OpenCart itself, for every extension on the store. Back In Stock installs and works there, and says so on its own screen with the address to use.

A store below OpenCart 4.0.2.0 is refused and says so on the screen rather than half-installing: no tables, no settings, nothing.

4.0.2.0, 4.0.2.1, 4.0.2.2, 4.0.2.3, 4.1.0.0, 4.1.0.1, 4.1.0.2, 4.1.0.3 and 4.1.0.4 are the releases a full install-and-run pass has been through, and they are the only ones claimed. A newer release installs and runs, and the settings screen says it is untested. Untested does not mean known to be broken.

What Back In Stock stores

Six tables of its own, all prefixed with your store's table prefix and the extension's code: the subscriptions themselves, the per-product switches, the consent wording versions, the consent records that outlive a subscription, the suppression list, and one small table Back In Stock uses to remember your settings across an update.

No OpenCart table is changed and no core file is edited.

The shopper's IP address is never recorded, at sign-up, at confirmation or anywhere else. What is kept about a person is their address, what they asked about, when they asked, and the exact wording they read.

Updating to a newer version

Follow updating to a newer version in the order it gives. An update is an uninstall followed by an install as far as OpenCart is concerned, and Back In Stock is built for that:

  • Nothing on the waiting list is lost, and neither are the consent records or the suppression list. No table is dropped by anything this extension does.
  • Your settings come back, including the retention periods. That matters here because those periods are sentences inside the notice people were shown.
  • The sweep secret is the same afterwards. A crontab line already pasted somewhere keeps working.
  • A scheduled sweep you switched off stays off, on the cycle you chose.
  • Your wording comes back. Both emails, the consent notice and the heading above the capture form are settings, so an update leaves what you wrote alone (see changing what the emails say). Updating from a release that kept the wording in files under extension/back_in_stock/data/ reads whatever you had edited there one last time and puts it in the boxes, so check them afterwards (see the changelog).