WooCommerce classifies an allowed backorder as the possibility to order items that are not in stock at all. These items thus get a negative stock and have to be reordered – usually this extends the time until the item arrives at the customer.
Since we have to show delivery times, however, we then get a problem, because the originally stated delivery time is exceeded by the reorder. We want to avoid this: Items that arrive too late to the customer make dissatisfied, which would be reflected in bad reviews.
Suppose we sell and ship our items to Germany, which takes 2-3 business days each. If an ordered item is no longer in stock, we have to reorder and in this case the item will not arrive at the customer until 2-3 months. We want to map this deviating delivery time and we show you how you can implement this.
WooCommerce Product Editing Enhanced
Step 1: We need the ability at the product level to indicate how long it will take for an item on back order to reach the customer.
We can do this by first building an additional element with the stock options as above.
For this we hook ourselves at
and place our selection there with the delivery times provided by Germanized:
Step 2: Now we have to make sure that the delivery time is saved as meta information for the product in case of backorder. To do this we hook into
Step 3: We configure Germanized to hide the delivery time in case of backorder.
We can find that under WooCommerce > Settings > Germanized > Shopmarks > bDelivery times.
And that was already the whole customization in the backend. With this, we can select from the specified delivery times the one that will be displayed in case of a backorder on the product. That’s what we’re going to take care of now.
Display of Delivery Time in case of Backorder in the Product
In the product view, we want to show our fallback delivery time if it is a backordered product, meaning it is out of stock. To do this, we hook into Germanized in
and output our fallback delivery time for the backorder.
Because of actions and filters that we can hook into, it is often possible to implement complex changes or extensions with just a few lines of code.
When we develop such functions as above, we do it at best on the same infrastructure the production system is running on, but of course not in the production system itself.
It gets a bit tricky when we want to “deploy” the functions developed in the staging system to the production system. For larger projects, versioning software such as Git is often used for this purpose. Manually, a deployment of extensive changes to the production system would look like this:
Such workflows are absolutely essential for systems that are constantly changing. For example, in high-turnover online stores where orders are continuously received. We want to achieve a balance between short donwtime and extensive functional tests.
Actions and filters don’t only work with WooCommerce and Germanized, by the way. Many plugins, and even WordPress itself, offer corresponding docking points to change functions or return value.
By the way, filters always return a return value, but actions do not.