WordPress Philosophy seems to indicate that all design decisions are ultimately run by the user base to get a "democratic" voting of what changes to implement or reject. However, the reality is far from that. Is WordPress missing a "voting" system?
Recount of my impressions of being a first-time volunteer and first-time speaker at a WordCamp, two personal premieres I was able to experience at WordCamp Frankfurt 2016.
While the first part of this series identified the need to separate business-specific logic from reusable code, we haven't yet discussed how to best achieve this. Let's try to think it through...
How do you sell benefits when your potential customers haven't faced the problems yet? Sometimes, concepts that are useful and necessary in a given context are rendered meaningless when applied to a different context, making it difficult to explain these concepts in a handful of slides.
OOP lures you with the promise of making code reusable, but OOP syntax alone does not make your code reusable. Let's find out why that is, and how to really write reusable code.
There are different approaches to bust the cache when your static assets have changed. I'll briefly touch upon the most common one before describing the method I use on my sites.
Having a constructor in an interface is a bad idea, even though PHP might allow it. In this article, I want to explore the reasoning behind that statement.
Wrapping procedural code is known as "Poor Man's Namespacing". While it does help avoid namespace collisions in legacy code, it is still procedural code. OOP is not about syntax.
"Object-Oriented Programming - No Object-Oriented Benefit" - a series of articles on how NOT to write OOP PHP code.
Including an autoloader within WordPress is not an all-or-nothing endeavour. With a few simple changes, we can have a fully functional autoloader being loaded with WordPress, and we can start refactoring the existing Core code to gradually load more and more classes (and even functions) through the autoloader.