Tags: php

3 open source link shorteners [↗]

Want to build your own URL shortener? These open source projects make it easy.

I quite fancy having my own URL shortener — it’s mentioned on the IndieWeb ‘Getting Started’ page, which is something I’ve been looking at getting involved in. The thing is, I’d need to register a new short domain and I’m not sure I want to do that. Anyhow, if I were to go down this route, the 3 URL shorteners in this article are all written in PHP and are worth investigating further.

Using HTTP/2 Responsibly: Adapting for Users [↗]

A useful article that explores how best to implement HTTP/2. Includes this helpful snippet:

The specific mechanism by which you detect HTTP/2 support will depend on the back end language you use. In PHP, we can determine the protocol version of a given connection by checking the $_SERVER["SERVER_PROTOCOL"] environment variable. Below is a one-liner that stores the HTTP/2 connection status in a variable named $isHttp2:

$isHttp2 = stristr($_SERVER["SERVER_PROTOCOL"], "HTTP/2") ? true : false;

Using the stristr function, the $_SERVER["SERVER_PROTOCOL"] environment variable is checked for the presence of the substring "HTTP/2". If the substring exists, $isHttp2 is set to true.

I’ve not checked, but I wonder if the Autoptimize WordPress plugin has options for this?

Conditionally include additional CSS and JavaScript for page templates in WordPress

I’m currently working on a large’ish WordPress theme that has a number of custom page templates. The custom page templates require their own CSS and JavaScript files, so I’m using the following code to enqueue the additional files. This allows for a file structure like so:

themes/mytheme/page_template_foo.php // custom page template
themes/mytheme/css/page_template_foo.css // additional CSS
themes/mytheme/js/page_template_foo.js // additional JS

The code should be self-explanatory, but see the comments for explanations as to what’s happening.

Notes: this method increases overheads as it tests for the existence of files, if you’ve only got a couple of custom page templates, you’d be better off hardcoding. That said, if you’re using caching it shouldn’t be a big deal. Also, unless you’re using HTTP/2, you’ll probably want to use something like Autoptimize to concatenate the CSS and JS files.

WordPress Stigma

I came across the following comment today, it’s a prime example of the stigma attached to WordPress and its developers:

The average WordPress developer writing themes and half-assed WordPress plugins doesn’t have the know-how and skills to get hired in a serious PHP app shop, and the people who can get hired in a serious PHP app shop can’t stand WordPress and its entire ecosystem.

So they’re basically two different markets, two different ecosystems. WordPress even has its own coding standard that’s incompatible with the PSR-s, and its best practices are precisely what a PHP developer would never be caught doing, such as littering their codebase with global variables and top-level code scattered around include files.

I’m about 9 months into my WordPress adoption experiment and I’m still loving it. Having previously used PHP frameworks such as Laravel, Symfony and CodeIgniter, I’m fully aware of the WordPress stigma, but in all honesty, I don’t care. Developing for WordPress is fun!

If I had to choose, I’d take working with WordPress over working for a “serious PHP app shop” every day of the week.

Also, NASA.

A Response To PHP – The Wrong Way [↗]

For anyone who isn’t aware, there is a site call http://phptherightway.com, which is a summary of good (dare I say, best?) practices for writing PHP in 2016.

In addition, there now exists http://phpthewrongway.com, whose aim is to provide a kind of counterbalance to http://phptherightway.com and what is presently mainstream PHP culture. This article is a rebuttal to the arguments found in http://phpthewrongway.com.

Some people have way too much time on their hands. That said, I did enjoy reading phpthewrongway.com — I’m definitely more aligned with “the wrong way” of thinking about these things.

Spelunking into the Template Hierarchy [↗]

The template hierarchy is one of my favorite features in WordPress. It not only makes child themes possible, but it also makes the whole ecosystem better because more code can be written to sit in smaller and smaller chunks. This is great. What’s also cool about it is that it’s all enabled by a few relatively small chunks of code. But staring at them starts to expose us to some of the most interesting parts of WordPress.

A nice post exploring the WordPress template hierarchy.

On a semi-related note; it’s been a good 8 months since I started my 10,000 hours of WordPress experiment. If I’m honest, I have no idea how many hours I’ve actually spent working with WordPress, it’s a lot, but I don’t think I’m close to 10,000 yet.

Regardless of the number of hours, I’m still really enjoying working with it, which I’m quite surprised about — when I started, I was a little concerned that WordPress might not have enough complexity to keep me interested, but I’m glad to say that my concerns were unwarranted. I’m still finding new and interesting ways to work with it and I’m having lots of fun. At this point in time, I’d probably describe myself as fully signed-up WordPress convert, which sounds a little weird, but there you go.

WordPress crusade against technical responsibility [↗]

It is often stressed in WordPress circles that plugins and themes should be compatible to obsolete 5.2 version of PHP programming language.


Because otherwise you will break people’s sites.


Because people still run their sites on PHP 5.2.


Because they don’t know they should update.


Because we won’t tell them.


Because they don’t have to know.

Wait, what?

It took me a long time to grasp that “they don’t have to know” is one of the most important and least obvious WordPress principles.

I don’t agree with that.

I don’t agree with it either, it’s insane. WordPress has more than enough security concerns without the added issues of supporting dead versions of PHP. Bonkers.

BTW, this WP site runs on PHP v7.0.9 and it really wasn’t very difficult to achieve.

Powering Raspberry Pi Projects with PHP [↗]

PiPHP: GPIO is a PHP library that can be installed via composer that allows you to control these GPIO pins. Here is an example of how we might use the library to blink an LED a few times when a button press is detected.

A nice and simple introduction to programming a Raspberry Pi with PHP. For many developers, I would imagine Python would be their first choice for this type of thing, but it’s nice to know there are alternatives available.

Abusing the WordPress REST API

Earlier, I was playing around with the WordPress REST API and I was struggling to figure out why the WordPress function is_user_logged_in() was not working with my custom endpoint. The function returns false regardless of whether the user is logged in or not. Turns out, this is by design and I needed to send a nonce within my endpoint request. Doh.

Anyhow, before I figured this out (RTFM, Philip), I came up with a rather fugly workaround. The hack was to add an action to the rest_api_init hook, call the is_user_logged_in() function and set a global variable, which could then be accessed from within the endpoint. Now, I’m not sure I would recommend using this hack, but it did occur to me that there could be a scenario where it’s not possible to send a nonse with the request, in which case the only way to test if the user is logged-in would be within the endpoint’s code.

How bad am I?

5 New Features in PHP 7 [↗]

So what makes PHP 7 so special? What does this mean for you as a developer?

A good write-up of the new features in PHP 7. I’ve been using PHP 7 with a few projects at work, but I’ve not managed to use the new spaceship operator yet. This makes me sad :(

◀ Older