The plugin that decides when a restaurant group can say yes

Why it exists

Scheduling rules in food retail are not a calendar — they're a precedence problem. A Christmas rule has to beat the standard bakery rule. A mixed cart has to resolve to one honest answer rather than the union of everything. A venue that does pickup but not delivery has to say so before checkout, not after payment. The existing plugin in this space handles the simple case and then makes you fight it. I encoded the real rules instead.

How it resolves

One rule covers a category or a set of products, over either a fixed date window or recurring weekdays, optionally restricted to specific venues. Rules carry a numeric priority where the lowest number wins, and in a mixed cart the lowest priority number drives the whole checkout calendar — so a festive item pulls the entire order onto festive rules rather than producing two conflicting pickers. On top of that: a global cutoff in hours before the slot, per-rule minimum and maximum lead days, and per-product daily quantity limits enforced against every item in the cart. Blocked dates can be global or per rule, whole-day or per slot, and scoped to pickup, to delivery, to specific venues or to specific shipping methods. Free-delivery windows zero the delivery cost only when every scheduled item in the cart qualifies on the chosen date. The priority convention deliberately matches the incumbent plugin's, so migrating off it doesn't mean re-learning the mental model.

The operations side

The half that gets used most isn't customer-facing. An admin calendar shows every rule across the month, filterable by category, venue and fulfillment method, with blocked days drawn as blocked and labelled with the note explaining why and which rule set it — so 'why can't customers order this on the 24th' is one click, not an investigation. And the CSV export by fulfillment date is what kitchen prep lists and delivery batching are actually built from. That export is the reason the plugin earns its keep.

The honest constraint

The built-in picker renders through classic checkout hooks, which WooCommerce's newer block-based checkout doesn't run. Rather than half-support it, the plugin declares itself incompatible with cart and checkout blocks so WooCommerce warns you properly, and shows an admin notice if it detects the block on your checkout page. The picker also ships switched off, so a site with its own custom checkout can drive the selection itself and use the plugin purely as the rules engine. Stating a limitation plainly beats a customer discovering it at payment.

What it proves

That when the digital estate needs something the plugin market doesn't sell, I don't file a ticket and wait. This is production PHP running against a live checkout for a real restaurant group — the least glamorous and most load-bearing thing in this list.

Stack