Giving a messy WordPress plugin a real architecture
A client’s membership plugin had grown into a fragile mess over five years and three developers. The fix was not another patch but a central manager class to bootstrap it.
A client’s membership plugin had grown into a fragile mess over five years and three developers. The fix was not another patch but a central manager class to bootstrap it.
A client’s site kept redirecting to a pharma store no matter how many times they cleaned it. The malware was only the symptom; an outdated plugin left a backdoor open.
A client’s plugin had a 200-line constructor stuffed with add_action and add_filter calls, so the class could not be tested or reused. Keep hooks out of the constructor.
A WooCommerce store’s coupons applied at random because functions kept overwriting shared globals. Wrapping the logic in a class with private data and public methods fixed it.
A walk through using a WordPress abstract class as a shared blueprint for plugin admin pages, so adding a new option means editing one child class instead of six copy-pasted files.
A client’s site was slow and under constant brute-force attacks on xmlrpc.php. The fix wasn’t blocking IPs but understanding WordPress entry points and closing the unused ones.
A client’s analytics plugin was one giant static class. Why overusing the WordPress static keyword breaks down, and how refactoring to a stateful object fixed it.
A WooCommerce thank-you message kept breaking because of a fragile concatenated string. Here’s how sprintf cleans up PHP string formatting and handles missing data.
Syncing users between two WordPress sites, I built a small REST API client on WordPress’s own WP_Http class instead of pulling in Guzzle. It uses dependency injection and returns WP_Error on failure.
A tangled inventory plugin had hooks and direct class calls everywhere. Treating the WordPress Plugin API as the mediator, with hooks in a dedicated subscriber class, keeps the core logic clean and testable.