Pretty much everyone who develops with PHP uses Composer, and if you’ve every used a PHP framework, you’ve seen the namespaces at the tops of files. I knew how to use these things but I didn’t really understand them until I embarked on a few just-for-learning side projects that I started from scratch.
Log files are just good practice; not only can they help in development and debugging, but they can act as silent sentinels, watching over your code and helping you find a quick solutions when things go wrong.
Have you ever written plugin code in WordPress that was dependent on another plugin to run? If your code tries to execute before the plugin you require has loaded, obviously, it won’t work. There’s a very simple way to make sure that your plugin doesn’t run until it’s ready.
As a developer, you’ve no doubt been asked “can you do [insert user request here]” more times than you can count. The answer is pretty much always “yes.” The tougher question these days is “how” … there are hundreds of ways to get things done these days. In this post, I’d like to share some of the things that shape my decisions about the “how.”
WordPress uses wp_posts to store post, page, and Custom Post Type (CPT) data the wp_postmeta table for Custom Metabox data. To retrieve this data you have to read for the post plus multiple linked postmeta rows. In this post, we conquer postmeta with subqueries.
With over 50K packages in the WordPress.org plugin repository – all open source – the code within these plugins is all over the place. Into this picture enter the WordPress Plugin Boilerplate. In their own words, the Boilerplate is “a standardized, organized, object-oriented foundation for building high-quality WordPress Plugins.”