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.
I have been working on refining my development workflow for some time now, in order to optimize the quality of my code. And as I am a big fan of automation, I tend to look for tools that just do their work in the background and only need my input when my mental processing power is truly needed. This leads to a greater focus on the coding and problem solving area of development.
One of the areas that was missing a satisfactory solution so far was the
pre-commit checks that
git was doing when new changes were committed to a repository. I had a bash script that was provided with my code, together with a small instruction in the
README.md file that was explaining how to symlink that file into the
.git/hooks folder. It did work, but it needed manual interaction first in order to be able to do its work.
Ryan McCue, Senior Engineer at Human Made and WordPress Core Developer, has posted a series of tweets regarding the fact that WordPress is far from an ideal platform for developers, which has spawned a lot of discussion.
As a long-form response to this, here’s a list of changes I would like to see in WordPress, and how I would try to address backward compatibility (BC) concerns. I don’t pretend to know that this is the absolute best way to tackle the problem, this is purely my own biased opinion, and how I would try to fix the issues if I were in charge.
A question came back about the constructor syntax I was using, and how that actually worked. I’ll use the opportunity to write the answer in form of a blog post, as I think that this is a concept that might be new to a lot of WordPress developers.
Link to GitHub Repository: PHPFeature
I had a short conversation on Twitter the other day with Andrey Savchenko ( @Rarst ). He was wondering whether feature-centric PHP requirements would work in WordPress extensions.
Although he was talking about the features of the “WP extensions”, I asked myself why there was no feature detection library available for PHP, similar to what Modernizr does for the browser features. Traditionally, PHP requirements are always based on a version number constant.