How autoload in the WordPress Options API can slow your site
A plugin stuffed 2MB of logs into one autoloaded option and dragged every page down. Here is how the Options API autoload flag works and how to split the data properly.
A plugin stuffed 2MB of logs into one autoloaded option and dragged every page down. Here is how the Options API autoload flag works and how to split the data properly.
Hooks buried in class constructors made a WooCommerce plugin impossible to follow. Here is how a small PHP interface and a hook manager give every class a clear, testable contract.
A client asked for one small change to a meme shortcode plugin, but its 2,000-line class made every edit risky. Splitting it by responsibility fixed that.
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.