How to plan a software project so you actually ship
A client had coded for three months with nothing finished. The fix was not more features but planning work in vertical scopes, each one a complete, shippable slice of the product.
A client had coded for three months with nothing finished. The fix was not more features but planning work in vertical scopes, each one a complete, shippable slice of the product.
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.
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.