Tag: PHP (Page 11 of 12)

Using Nullable Return Types in PHP

June 26, 2018 / Tom

“One of the nicest features that PHP affords is type hinting specifically for those who are coming from an object-oriented programming background.

From the PHP manual:

Type declarations allow functions to require that parameters are of a certain type at call time. If the given value is of the incorrect type, then an error is generated: in PHP 5, this will be a recoverable fatal error, while PHP 7 will throw a TypeError exception.

The reason this is important is because it gives people who are going to use your code – specifcally those who will write code against your code – what types of parameters a given constructor or function will accept.

But there’s more to it than that because type hints are also applicable to the type of data a function can return.

Sanitizing URLs in WordPress with Its API and Built-In PHP Functions

June 14, 2018 / Tom

Working with user-centric fields in WordPress – such as input elements, textarea elements, or any type of field in which a user can supply their own values is a place that should always be a target of sanitization.

Sanitizing URLs in WordPress with Its API

Fortunately, the WordPress API provides a number of functions to help with this. Depending on your use case, you may need to do one of the following:

And those are all well and good but there are also ways in which you can work to sanitize the data using functions provided by PHP.

Sure, sometimes regular expressions are the way to go but, other times, you may want to use facilities that are built into the language, easier to understand, and easier to follow.

When writing my own code (and when reviewing others) I try to keep that in mind. So with that said, here’s a process that you can use that may make your efforts easier when working with URLs in WordPress.

Does WordPress Hold You Back as a Developer, Really?

May 22, 2018 / Tom

One of the commentaries that we often read or hear about WordPress is its “low barrier to entry” and why this is good for the web.

The counterpoint to this is that it prevents developers (or “would-be developers,” as some may say) from embracing more modern technologies because WordPress doesn’t require them.

Does WordPress Hold You Back?

To be honest, I’ve even seen some go as far as to say that if someone says they are a PHP developer who has primarily worked in WordPress for their career, then you should subtract, say, three years from their “real” PHP experience.

Yikes.

I see reasons for this – I’m guilty of some of the “older” practices – but does that mean that WordPress prevents us from becoming high-quality, object-oriented programmers?

Running Multiple Versions of PHP with Homebrew

May 2, 2018 / Tom

One of the challenges with building solutions on WordPress is working with the various environments each host provides.

That is, some are still running very old versions of PHP; others are running newer versions, but even then there are variations among them.

Case in point: I’ve been running PHP 7.2 on my local machine for development for some time; however, I’m currently on a project where a few of the dependencies on the continuous integration tool offers support only for PHP 7.1.

And because I like my development environment to mirror the staging and production environments, I think it’s important to make sure there’s parity.

If you’re using a package manager, it’s pretty easy to get going with multiple of versions of PHP with Homebrew, but you may run into a couple of snags as it relates to running it alongside Valet.

When Valet Stops Working Properly, What Do We Do?

April 30, 2018 / Tom

I’m a fan of using both Homebrew and Valet when it comes to setting up and configuring a basic WordPress development environment. Though using package managers and simple software for such like this should make things easier, it doesn’t absolve us from the occasional problems.

Case in point: There are times in which we may have to update our TLD to play nicely with Chrome and other browsers, or even upgrade the entire installation.

Unfortunately, it’s not always as easy as it should be. Technically, we should be able to uninstall Valet and update it via Composer. But I’ve personally run into some problems that relegated having to:

manually uninstall Valet,
use Homebrew to uninstall PHP and clean up what was left completely,
reinstall Homebrew packages,
install Valet,
verify the browser uses the same version of PHP as the installation of Valet.

It sounds like a lot of work for something that should more or less “just work” and it is quite a few steps, but they are pretty quick to set up.