Reference¶
The enumerable parts of this section (the settings, and the states a pre-order
can be in) are written from the extension's own code by oce docs:reference, so
they cannot drift away from what the version you installed does.
- Settings: every setting, its default and what it does, alongside what Pre-Order fixes on purpose and why.
- The API: the two read resources an integration may call, every field on each, and what the promise covers.
- What a pre-order can say: the four line states, the order state above them, and the three order statuses.
Where things are¶
The screen is at Extensions → Extensions → Modules → Pre-Order, and
carries two tabs: Pre-orders and Settings. Its route, which is also the
permission you grant, is extension/preorder/module/preorder.
The product tab is on the product's own edit form in Catalog → Products, at the end of its row of tabs. It is where a pre-order is created; the module screen holds store-wide policy only.
The payment method is at Extensions → Extensions → Payments → Pre-Order. It is the placeholder a deferred pre-order is taken with. It charges nothing and writes Pre-Order Received. It is installed and switched on when the module is enabled, and removed when the module is uninstalled. Nothing on it needs configuring.
The data-protection screens are Customers → Personal Data, which answers what the store holds about one person, and the remove-everything screen the settings screen links to. Their permissions are on requirements and install.
The order statuses are in System → Localisation → Order Statuses, and are described on what a pre-order can say.
The tables, all prefixed the way your store prefixes core's:
| Table | Holds |
|---|---|
preorder_setting |
What you marked: a product, or one option value of one, with its date and payment mode |
preorder_order_product |
One row per pre-order line of an order, and what became of it |
preorder_order |
One payment link per order, and whether its reminder has gone |
preorder_memory |
The copy of your settings that survives an update, and the ids of the three order statuses |
None of them is ever dropped. Removing them is something you do yourself against the database, not something a screen here offers. The statement is on limits and guarantees.
The routes:
| Route | What it is |
|---|---|
extension/preorder/preorder/preorder.pay |
The page an emailed payment link opens |
extension/preorder/payment/preorder |
The placeholder that takes a deferred order |
extension/preorder/cron/preorder |
The daily reminder and expiry pass. It admits OpenCart's own scheduler, or a caller holding the secret in the Sweep address; anybody else gets a 404 |
extension/preorder/cli/preorder |
The same pass from a terminal, reached by php extension/preorder/preorder.php. It refuses anything that is not a terminal |
The emails, both to the customer and both plain text, sent through your store's own mail engine:
| When | |
|---|---|
| Your pre-order #N is ready to pay | A payment request goes out, or is reissued |
| A reminder about your pre-order #N | Once, halfway through the payment window |
Nothing else is emailed by this extension. Cancelling a line and expiring an order send nothing, and releasing a line early sends nothing unless it was the last line the order was waiting on, when the payment request goes out.
Your store's own order-confirmation email still goes out when a pre-order is placed, exactly as it does for any order. That email is OpenCart's, not Pre-Order's. For a deferred pre-order it names Pre-Order as the payment method and Pre-Order Received as the status, and carries core's own line about the order being processed once payment is confirmed, which is what happens. Your usual new-order alert reaches you at the same moment. Nothing is emailed earlier than that: the order exists from the moment the confirm page is rendered, but it carries no status, and so sends nothing, until the pre-order is taken.
The scheduled row is at Extensions → Cron Jobs, runs daily, and is registered when the module is enabled. It sends the reminder and marks unpaid orders expired, and it decides nothing: whether a payment link is dead is worked out when the link is opened.
What a generated list cannot tell you is which of these you should change, and what happens when you do. That is guides and limits and guarantees.