Omnibus is not a plugin you install, it is a price history that WooCommerce does not keep by default. So if you have typed omnibus woocommerce into a search box, you were probably looking for one plugin that settles the whole thing in five minutes, and you landed either on a list of plugins or on a law firm article about information duties. Both skip the question that actually decides how Omnibus in WooCommerce gets implemented: where is your store supposed to learn what that product cost three weeks ago?
The rule in short: when you announce a price reduction, the new price has to be accompanied by the lowest price from the last 30 days before that reduction. It is an information duty that came in with the Omnibus directive and it applies to any store selling to consumers. One disclaimer up front - I write this as someone who builds this into stores, not as a lawyer. How exactly to word the message, what counts as announcing a reduction and how to treat unusual discount campaigns are questions for your lawyer or your accountant. My part is making sure the store can show those numbers and that they do not drift.
In this post I go through what implementing Omnibus in an online store really consists of, where to find a price history nobody was recording, when a plugin is enough and when you need custom code, and what quietly breaks the mechanism after it is live.
Omnibus in WooCommerce - how to show the lowest price from the last 30 days
Technically this is not one mechanism but three, and each of them can break independently of the others.
The first one is recording price history. WooCommerce stores a regular price and a sale price on the product, but it only stores the values that apply right now. You change a price from 199 to 149 and the old 199 simply stops existing - there is no log the store could look into two weeks later. Until you add something, your store knows nothing about its own pricing past.
The second one is calculating the minimum over the 30-day window counted back from the moment of the reduction. This is where the decisions start: do you count only prices that were visible to everyone, or previous promotional prices too; what about the period when the product was out of stock; and at what hour does a day begin. It sounds like a detail, but on products that go on sale every other week that difference shows up in the message customers read.
The third one is displaying the information wherever the customer sees the price. This is where I find gaps most often: the message sits nicely on the product page and never appears on the category listing, in the store search results, in a featured product tile, in the cart or in the order confirmation email. If you announce the reduction on a category page, the information belongs where you announce it.
What helps: before you pick a tool, write down every place in your store where you show a struck-through price. That list is your test checklist, and it is usually longer than people expect.
Where to get a price history nobody was recording
This is the most common collision with reality. A plugin installed today starts recording prices today, so for the first few weeks its log is almost empty. Good tools behave carefully in that situation - they either show nothing or show a price from a shorter period with a note - but they still cannot conjure up data nobody saved.
History can be recovered if you keep it somewhere outside the store:
- ERP or warehouse software - if prices enter the store from outside, that is where the real change history lives, often with dates.
- Product exports - if somebody generated a CSV or XML price file on a schedule, each of those files is a snapshot of prices on a given day.
- Database backups - a backup from a few weeks ago contains the prices from that day; tedious, but workable.
- Advertising feeds - the files you send to shopping engines and to Google carry prices with a send date.
If none of that exists, there is one honest way out: start recording from today and hold off on announcing reductions for products where you have nothing to back the message with. That is a business decision more than a technical one, and it is worth talking through with a lawyer rather than putting numbers into the store that you cannot defend.
What helps: if your first big sales campaign is still ahead of you, switch price history recording on a month earlier. Then the mechanism has something to feed on the day you actually need it.
Plugin or custom code
A plugin is enough in most stores and that is usually my first recommendation. Three conditions: it gets updates and somebody clearly maintains it; it adds the message in every place where your theme shows a price; and it does not require you to edit theme files, because those edits evaporate with the next theme update.
Custom code wins when the price in your store is not a plain field in the admin panel:
- prices arrive from an ERP or a supplier and change automatically several times a week,
- you run wholesale prices and per-role price lists, so one product carries several prices at once,
- the way the price is presented is unusual, because a theme or a configurator recalculates it on its own,
- promotions are fired from an external system rather than from the WooCommerce sale price field.
When you compare plugins, count the cost the way you would count any other one - with maintenance included, not just the licence, because the real cost of WooCommerce plugins rarely stops at the first year. And as with any change that touches prices, you update a tool like this one step at a time with a backup at hand, not in bulk on a live store on a Friday.
If you are not sure which case you are in, half an hour in the admin panel and in the theme code usually settles it. I run that assessment at the start of every WooCommerce store I take on, because it decides whether configuration is enough or a custom mechanism has to be built.
The traps that break this quietly
The worst thing about Omnibus is that a broken implementation looks exactly like a working one. The message is there, a number is displayed, the number is just wrong. What I always check:
- Variable products. Every variation has its own price, so its own history too. The store has to show the minimum for the specific size or colour the customer picked, not for the cheapest variation in the product.
- Scheduled sale prices. WooCommerce can start a promotion on a date. The history mechanism has to react to the moment a price changes on its own, with no human involved.
- Coupons and cart discounts. A discount applied in the cart is a different situation from a reduced price on the product page. Whether a given campaign counts as announcing a reduction is a question for your lawyer, but the store has to be configured in line with what you settle and must not mix the two.
- Price imports. A daily import from a supplier or an ERP can overwrite prices on a thousand products and either flood the log with noise or bypass it completely, if it writes prices through a different route than the admin panel. It is the same problem I describe around importing products from supplier files.
- Caching. A product page held in cache will keep showing yesterday’s lowest price long after the change. With prices, the cache has to be cleared together with the price.
- Time zones. The server, WordPress and the ERP can easily hold three different clock settings. On a window counted in days, that is a real difference at the edge of the period.
What helps: I test on a single product, from the far end. I change its price up and down a few times, write down what I set and when, and then check whether the message in the store agrees with my notes. Until it agrees on one product, there is no point looking at the whole catalogue.
What the regulator checks
One practical thing worth knowing: an inspection does not look into your database, it looks at the store the way a customer sees it. What counts is what is on the page at the moment the reduction is announced - in search results, on the category listing, on the product page, in a banner on the home page. A screenshot from your store is the easiest evidence there is to collect, and not only for the consumer protection authority (in Poland that is UOKiK) - a competitor or a customer can file a complaint just as easily.
That is why I check an implementation from two sides: in the admin panel, to see whether the data is being recorded, and in a private browser window, to see whether the customer really gets what they should. A mismatch between those two is the most common outcome of such a review.
What the consequences of missing this information are and how their size is calculated I will not quote from memory, because that is legal rather than technical ground. Penalties in this area are tied to company turnover, so a conversation with a lawyer is cheaper here than guessing. My half of the answer is simple: the store has to be able to show a true number in every place where you announce a reduction, and it has to keep doing it after the next plugin update.
Summary
Omnibus in WooCommerce breaks down into three things: recording price history, calculating the lowest price from the last 30 days, and showing it everywhere the customer sees a struck-through price. The store does not have that history out of the box, so implementation starts with the question of where the data comes from, not with picking a plugin. In a typical store a plugin is enough; in a store with prices from an ERP, per-role price lists or an unusual price presentation you need custom code. Variations, price imports and caching cause the most trouble, because they break the number rather than the message - which is exactly why nobody notices.
If you run promotions and you are not sure the lowest price you display is calculated correctly, send me a link and the name of one product that was recently on sale. I will check what the customer sees, what sits in the data, and where those two diverge.
Frequently asked questions
Is one plugin enough to put Omnibus behind me? In a typical store, yes, provided it shows the message in every place with a price and provided it is maintained. The trouble starts where prices enter the store automatically, or where one product carries several prices for different customer groups - a plugin alone is usually not enough there.
What do I do if my store was not recording price history? Recover it from the ERP, from product exports, from advertising feeds or from database backups, and if none of those exist, switch recording on now and hold off on announcing reductions for products you cannot back up. How to describe the period before recording started is something to settle with a lawyer.
Does the information have to sit next to every price in the store? The information has to accompany the announcement of a reduction. If you announce it on a category listing and in a banner, it has to be visible there too, not only on the product page. That is why I list every place where the store shows a struck-through price before implementing anything.
Does this affect store speed? With price history recorded properly it should not, because it is one extra read when the price is rendered. It starts to hurt noticeably only when a plugin calculates the minimum live on every visit to a category listing instead of keeping the computed value on the product. That is one of the things I check in a review.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.