WordPress itself is not the problem.
Installing it on a fresh Debian server takes less than twenty minutes. WooCommerce takes three clicks. Lulu—for direct book sales—connected, first product visible. InvoiceNinja connected. Language plugin installed. Everything technically flawless, everything completed in a short time.
And then the real questions begin.
Every Requirement, a Plugin. Every Plugin, a Compromise.
WooCommerce doesn’t support multilingual stores out of the box. There’s a plugin for that—but it doesn’t fully support WooCommerce itself. Another plugin fills that gap, for an additional fee.
Multiple currencies? WooCommerce displays exactly two prices. Anyone who needs more buys an extension. The installed solution comes with a complete ecosystem: automatic exchange rate updates, converters, display options. For simply showing prices in three currencies, that’s a significant amount of overhead.
Lulu displays the book cover in the shop overview as a square crop—from the middle of the image. Book covers are portrait-oriented. The result is a useless crop. Solvable, but another project to tackle.
InvoiceNinja can be connected—technically correct. What that connection actually provides is an embed snippet, not true invoice integration between the two systems. Anyone who wants WooCommerce orders to appear directly as invoices in InvoiceNinja solves that differently—or with yet another plugin.
After installing the language plugin, the shop page was empty. Products were no longer visible. Somewhere, one plugin had overridden another. Which one, in what order, and why—wasn’t immediately apparent.
The Real Problem
WordPress is built for content, not for precise control. The plugin ecosystem follows the same logic: every plugin solves one problem completely—with everything that comes with it, whether you need it or not.
If you need a single feature, you get a product. If you need three features, you get three products that occasionally don’t know the other two exist. The theme that visually holds this stack together would still need adjustments after four hours of work.
The time required to set everything up properly would have been manageable. The question is whether the result remains controllable—or whether you’re operating a system you only partially understand.
What Works Instead
The same requirements—selling books, multiple languages, multiple currencies, invoicing—can be handled with small tools that do exactly what’s needed. No plugin ecosystem, no invisible dependencies, no empty shop page after an update.
This is not an argument against WordPress. For content websites with standard requirements, it’s a practical choice. For applications that require control and traceability, the plugin model is structurally the wrong tool.
