Tag: WordPress (Page 1 of 203)

Articles, tips, and resources for WordPress-based development.

Learn JavaScript, Forget PHP?

October 12, 2020 / Tom

The landscape of WordPress has changed.

time lapse photography of green field and clouds

A few years ago, we were all tasked with learning JavaScript deeply and rightly so. With the advent of Gutenberg and projects like Calypso, it’s obvious that JavaScript is becoming a dominant force in WordPress (not to mention the web as a whole), if you don’t consider it to be so already.

And for anyone who has read Coding Horror within the last decade or so, you’re likely familiar with Atwood’s Law:

any application that can be written in JavaScript, will eventually be written in JavaScript.
Jeff Atwood

But as this has happened, it seems as if its created a clearer divide between what constitutes a front-end developer and a back-end developer in the WordPress economy.

Personally, I welcome it as I find myself even more eager to learn, grow, and work on the back-end as PHP grows and changes. But that’s just me and there’s more to examine.

How To Change Local By Flywheel PHP Settings

September 25, 2020 / Tom

If you’re using Local by Flywheel to work on your projects, there may be times where you need to make customizations to the PHP configuration when the site starts.

Before getting started, note the following:

At a high-level, Local will start a containerized environment,
A containerized environment will have its own set of configuration every single time it starts
This means that you cannot change any configuration to the OS-level installation to achieve the changes you need.

So what do we do?

Setting Up PHP CodeSniffer Per Project

July 31, 2020 / Tom

A few years ago, I wrote a post about Setting Up PHP CodeSniffer in Visual Studio Code (and I’ve recently updated it, too).

But it’s been four years since that post was originally written and, in that time, a lot can change in terms of how we write code.

Four years is roughly an Internet Age, isn’t it?

Anyway, the basic points of that article still stand, but if you’re working on a variety of projects and some of them require different configurations, settings, and standards, then the way you go about installing and configuring PHP CodeSniffer may be different than how you configure it on a system-level.

So if you’re in that position, here’s how you can configure PHP CodeSniffer on a per project basis using Visual Studio Code.

Awesome WP-CLI: A First-Rate Starting Place

July 27, 2020 / Tom

One of the more challenging aspects of working with WordPress is working the fragmented nature of documentation. And I don’t necessarily mean the Codex nor do I mean the Developer Resources.

But I mean the fact that there’s a ton of information spread across blogs (mine not exempt), subreddits, questions and answers on Stack Exchange, and shares via Twitter, and so on.

I’m not making a case that this is inherently bad or good but I am making the case that when given the opportunity to provide a central repository of information for a feature, set of APIs, or tools that it can be extremely helpful especially if it’s written an maintained by the author of something like one of the aforementioned issues.

Case in point: WP-CLI and Alain Schlesser.

De-coupling Domain Logic in WordPress

May 5, 2020 / Tom

Remember that WordPress uses the event-driven design pattern and although we often refer to actions and filters, the concept comes down to hooks. The flow of control through the program goes something like this:

Execute the program,
Whenever the program comes upon a hook (in WordPress, we’ll see do_action or apply_filters), iterate through all of the registered hooks,
Return control back to the program,
Execute until the end.

This isn’t completely different from the Publisher/Subscriber Pattern (or PubSub, for short) but there’s a key difference: The Event-Driven Pattern simply signals that something has happened and if there are hooks, they will fire. The PubSub Pattern will tell a registered subscriber to do something.

Anyway, back to hooks in WordPress. Keeping the two concepts of hooks that we have may be most easily done by thinking of them like this:

Actions are for doing something,
Filters are for processing data.

If you’re looking to approach WordPress development in an object-oriented fashion, tightly coupling your code to WordPress core by registering your classes via hooks to the core application is not a good idea.

In other words, don’t register your business logic with WordPress. Keep them separate. Here’s a litmus test for if your work is tightly coupled with WordPress: If you can’t run a unit test against your class without loading WordPress, it’s tightly coupled.

So what’s the solution? Delegation.