Originally published at: https://roots.io/upping-php-requirements-in-your-wordpress-themes-and-plugins/
There has been talk for a while now about the PHP requirements of WordPress. WordPress still supports PHP 5.2.4, however, PHP 5.2 was deprecated on January 6, 2011, over 4 years ago as of the time of this writing. PHP 5.3 was deprecated August 14, 2014. Why is WordPress continuing to support such antiquated versions…
2 Likes
@kalenjohnson Just a heads up, on the bottom of the blog post, the link to Discourse doesn’t work.
That being said, awesome blog post. I’ve been using Namespaces for quite some time, and I’m excited to see it growing into the Wordpress world. Super happy to be part of the Sage crew.
Thanks brandon, looks like it’s fixed now.
Good examples! I like that you showed how to use namespacing in actions/filters.
2 Likes
The only big thing I would add to this, regarding anonymous function, is that using them on filters/actions is generally not advisable, as other developers will be pretty much completely unable to unhook those functions if they wanted to. You remove hooks by name, but if the function doesn’t have a name, you’re SOL. This may not be a big deal for theme developers, as plugins aren’t generally unhooking theme hooks (in my experience, anyway), but I wouldn’t use them in plugins.
4 Likes
Very good point, and it’s true I didn’t mention specifically using it in themes, but that is probably the only place I would use anonymous functions with filters for the reason you mention.
Jeez, these PHP namespace changes are gonna take some time for me to fully comprehend.
Can’t see the benefits yet, but that’s probably just me…
It does take some getting used to. And I will admit that it’s slightly easier when using classes, since you can reference a class directly with the use keyword, so you don’t need to include the last namespace when using it, like you do with functions. But overall, it’s a good practice to get into.
It makes more and more sense the more you use it, and it especially starts to make sense when you are working on projects where you are pulling in other people’s code and packages. If you start using Composer for PHP packages, you’ll notice that most require at the very least PHP 5.3, if not 5.4+, and make good use of a lot of the functionality in this article, mostly namespaces and anonymous functions.
1 Like
one of my favorite tricks is to include a utility class at the root of the namespace. So instead of
namespace Foo\Bar;
function baz() {};
/**** Another file ****/
use Foo\Bar as bar;
bar\baz();
you can include a namespaced class and make calls from it.
namespace Foo;
class Bar {
static function baz() {}
}
/**** Another file ****/
use Foo\Bar as bar;
bar::baz();
The benefit to that is that once you get in to autoloading, your namespace can essentially load themselves without you having to worry about includes. I haven’t been using namespaces for very long and I already wish WP would drop 5.2.4 support so I could autoload without worrying about whether that particular class was included or not.
I actually didn’t think of using the as keyword with a namespace in use for functions. However if you’re just naming it the same as the last name then it sort of becomes redundant.
We’ve been talking a lot about autoloading now that it’s available and more built in to recent versions of PHP. The only issue like you said though is we’d basically need to create all classes filled with static functions, or else somehow make the theme much more object-oriented, and that doesn’t really seem in line with the original goal of Roots/Sage. Definitely open to ideas though 
Well, the alias example was a little contrived. When defining my namespaces, I’m usually more verbose about namespaces I am importing. When using a namespace inside another piece of code that likely won’t be looked at for documentation, I like to shorten the namespace with an alias. A better example might be
use Site\Plugin\Document as doc;
doc::doSomething();
I like saving those 5 characters. 
I had a little debate with a coworker about filling my code with static classes. While it doesn’t follow a traditional singleton pattern (which would seem a little silly to do in every plugin), the static class feels more like having a group of functions that have some memory. My arguments were
- I don’t think there’s any significant overhead added
- Autoloading is very convenient
- Code becomes more readable (though that may be just my opinion)
Regarding readability, I look at the method calls as library::function() rather than an actual class method. This seems to somewhat mirror how other languages are modeling their code as well (especially with the seemingly recent rise in closures within javascript).
However, if the static class route does add some discernable overhead or problems, I’m open to hearing them. It would be good to know if this is a bad code structuring path prior to committing to it 
Overhead? Don’t think so.
I just found this post, but I think it explains the reasoning behind when to use and not use static methods: When to Use Static Methods
It basically does come down to this quote:
Static methods are nothing more than namespaced global functions.
Which in a theme where we shouldn’t be doing much logic, it does make sense. It is important to take note of the reasoning he had behind stateless and stateful though. You don’t really want static classes to have “memory”, since you could use that same static method in a different part of code, or someone else can, and things can get messy. In that case, much better to not have static methods and simply new up your class.
Indeed. I’ll usually add a Class::init() call after my class definition, so it’s called when the class is autoloaded. This generally initializes some convenience properties like the plugin directory or url. I definitely try to avoid any properties that could change during execution, but it is an admittedly slippery slope sometimes.
Thanks for the read! It will be interesting to see what kind of community standards emerge as 5.3+ becomes mainstream in WordPress.
I’m still really figuring this new namespaces stuff out, but I was wundering if it’s common practice to change the default namespace Roots\Sage and change it into your theme name or leave it the way it is?
You can, but you don’t have to. I’ve changed it and I’ve left it on projects. Since Sage isn’t using any type of autoloading that relies on file names and folder names, so it’s pretty easy to change them all. Search and replace, really.
Ok thanks! For now I changed it, but I’ll probably won’t bother next time
I like the idea of using an anonymous function instead of declared function in cases where the function will be used once. Taken from the article:
add_filter('excerpt_length', function() {
return 20;
});
I usually document my declared functions with phpDocumentor-style docblocks. But how would you document the code above using phpDocumentor?