Securicate Hardware sells security equipment online. The request was one-off and precise: adding a customer from the shop's back office had become impossible. For a retailer that is not an interface detail, it is a sale that cannot be recorded.
The project in detail
The first thing I billed was not the fix, it was setting up a working environment. That deserves explaining, because it is counter-intuitive for a client expecting a quick repair. Hunting for the cause of a failure directly on a live shop means accepting two risks: making the failure worse, and deciding on the basis of observations you cannot reproduce. Building a faithful copy costs a few hours and makes the problem observable as many times as needed, switching the parts off and on one by one.
The installation went a long way towards explaining the difficulty. The shop ran on WordPress 4.8 with thirty active plugins, ten of which touched commerce: the shop layer itself, a second shop system installed alongside it, two French payment gateways, invoice generation, order export, live search and navigation, wish lists and a comparison tool. On top of that sat a visual page builder and its modules, a carousel, and a commercial theme paired with a child theme.
Thirty plugins on a shop is not a fault in itself: each was installed to answer a real need. But it means thirty different authors modifying the same admin screens, and a failure whose cause can come from any one of them or from two of them meeting. This is exactly the case where method matters more than knowledge of the code: you isolate, you reproduce, you test.
The engagement stopped there, at the diagnosis delivered and the tests. The report was not kept in the archives, so I will not say here which part was at fault: I would rather leave this page incomplete than reconstruct a conclusion nine years later. What remains verifiable is the request, the method and the exact state of the installation, found in the repository.