When the Plug-in Architecture Plugs-out

As expressed here before, the plug-in architecture of WordPress is amazingly capable when it works. But what do you do when the plug-in architecture plugs-out?

No wonder proper architects hate the use of the word 'architecture' in IT. If they built buildings like the software industry builds software, civilisation would be barely out of the ground and in imminent danger of collapse (quote: me).

Take the current client website. The website runs on the WordPress CMS. The client runs holiday activities for children. The holiday scheme is an event managed in an Events plug-in. The Events plug-in has a Tickets plug-in that does ticketing and attendance. However, the sale transaction is handed off to the online shopping cart. The online shop is managed by the WooCommerce plug-in, with a Stripe payment gateway plug-in.

Those five things are supposed to talk to each other seamlessly but there are... seams. This week, the seams are more like the Marianas Trench.

The default behaviour of the online shop sets the status of incoming orders as 'processing.' This allows for a Mk I human eyeball check before updating the status manually to 'completed'.

The ticketing plug-in adjusts the places taken in each activity at the time the payment is made.

Which is fine until the website, the hosted server or the Internet itself starts dilating time like we're accelerating to light speed. At this point the cart checkout sometimes - not always, and with no discernable pattern - takes forever to confirm the transaction. The customer's web-browser gives up with a time out message. So they attempt to buy the same thing again.

Except the transaction already completed. The customer doesn't know this. One customer placed the same order six times. Six payments. Six allocations of places taken from activities.
So you log in to the debris-strewn battlefield that is the Orders section of WooCommerce and refund the duplicate transactions.
But the online shop doesn't close the loop and release the places taken in activities when a refund is made. Updates flow downhill, they don't flow back up. The plug-in architecture is incomplete.

WooCommerce doesn't know to tell the ticketing and events plug-ins to reverse out their parts of the transaction.

It's a basic breach, not of referential integrity in the database, but of transaction integrity in the events and ticketing plug-ins. Because the WooCommerce order manager doesn't know that it should tell them that the transaction is reversed.

The plug-in architecture of WordPress is a marvel. It's a wonder - a wonder that any of it ever works at all. RC