Category Archives: Web Development

WordUp Brighton – WordPress Gems for Devs by Milana Cap

Last Tuesday I attended the WordUp Brighton WordPress meet up in Freedom Works Brighton. They had a talk from Milana Cap, a very active WordPress developer, covering recent additions to WordPress that developers may not know about. Milana streamed the talk from her home in Serbia and a copy of the talk is up on the Silicon Brighton YouTube channel.

WP HTML Tag Processor

First we were shown an example of using WP HTML Tag Processor, which lets you easily parse HTML within WordPress.

Milana used an example of spotting and removing “nofollow” from internal links which were to versions of the domain that didn’t match the set domain of the WordPress site. This was quite useful as it allowed her to show us a way the code could help in quickly parsing and changing some of the content of blog posts, but it was also a bit distracting as it’s the sort of problem I’d personally fix via updates to the database once, rather than having to run a fix every time a page loads, and that kept tripping me up while I was trying to think of ways I’d actually use HTML Tag Processor within the projects I do.

WP HTML Tag Processor looks like it could be useful and reminds me of Simple HTML DOM, a more general PHP HTML parser that I’ve used in a few projects in the past.

Interactivity API

The bulk of the talk was showing us ways to use the WordPress Interactivity API.

As I now understand it, this allows you to write PHP code within the WordPress block system and the API then builds/accesses various Preact Javascript code to do the interactivity part that you want. So, it sets up AJAX calls, shares data around, and live updates the page, all for you from quite a small amount of PHP. Milana built a simple example of this for us, and kindly linked out to some other examples from the documentation she’d put together for the talk.

I think this is potentially going to be very, very helpful for when I’m building interactive elements within a WordPress project as it’ll save me the time of writing Javascript code to handle AJAX, and API endpoints, by having all that code created by WordPress itself. It’s going to be very interesting to explore what the Interactivity API can do to help add small things to a project, e.g. search autocomplete, something I put in quite often but can be a bit of a faff to add.

Hopefully, the Interactivity API will catch on, which will make long term maintenance of sites and plugins more straightforward as they can use this within WordPress, rather than a site having multiple versions of jQuery, Vue or whatever.

Learning from learning

For me, watching live coding after a long day working on client projects was difficult. It did show us how little code needs to be written to get useful activity on the page, but I’d honestly have been fine with being shown a pre-built version and talked through what it was doing. By the end of the talk I was a bit torpid as I tried to process what we’d seen and come up with uses for it, and couldn’t think of any questions to ask, even though this is a really interesting feature that I hadn’t heard about.

I don’t mean this as a criticism of Milana, she was giving up her evening to present the talk to us and that was fantastic of her. This is a note to myself that if I’m going to an evening talk, I need to balance out what I’m doing during the day so I’ve enough mental energy to really process what I’m watching. I’ve got notes, but being able to understand more about what was going on with the code as I was watching would have been helpful.

Thanks

Big thanks to Milana for showing us these features, both of which I knew nothing about and could have missed out on using, and thanks to Paul Bunkham and Sim Brody for organising WordUp Brighton.

Using ACF Blocks by default in a new post in WordPress

One of my clients has a website using Advanced Custom Fields (ACF) Blocks to style everything in the site, including their News section.

To make a new post in News, they had to load a Pattern of the relevant Blocks. This being a multi-step process, and a bit annoying if you just want to get on with posting your article, I looked for a way to load the blocks into the new post by default.

You can do this by putting this code in your functions.php (with amends explained below)

function site_post_register_template() {
    $post_type_object = get_post_type_object( 'post' );
    $post_type_object->template = array(
        array( 'my-blocks/news-header' ),
        array( 'my-blocks/news-article' ),
        array( 'my-blocks/news-article-related' ),
    );
}
add_action( 'init', 'site_post_register_template' );

In this case, I have three Blocks loading – the specific header, the article, and a strip of related articles. I can load in as many Blocks as I want.

To make this work for you, find where you have saved your blocks and list them out in the same way, in an array for each.

You will have to change ‘my-blocks’ to the prefix of your ACF Blocks. To find that prefix, go to the directory where you store the code for the relevant Block and open the block.json file. Copy the details from the “name” line to be inside the array( '' ), above.

Now, when a new Post is started, it automatically loads in the ACF Blocks and my client can get on with posting their news, not thinking about how they load in the Pattern and where they left my instructions for doing so.

Fixing a Mailgun API unknown domain error

I’m using the Mailgun API for a couple of clients, making sure we don’t keep sending email to someone who has marked their previous message as spam.

It should be quite simple to use as the docs are very clear, but I kept getting an ‘unknown domain’ error in the returned message when I used the API with one of my client’s domains rather than the sandbox domain the Mailgun provides.

The fix was to use the EU address for the API: api.eu.mailgun.net rather than the standard api.mailgun.net. As my clients are in the UK, they are put into the EU servers, rather than the American ones.

I didn’t find a simple suggestion to do that, so I’m writing this so I find it next time this trips me up.

Fixing minor issues moving code from Railo to Lucee ColdFusion

I have a couple of personal projects at a host that offers the ColdFusion web programming language. I have a soft spot for ColdFusion as its my first programming language and I still find it very easy to put together sites in it as it comes with easy to use functionality the other server side language I use a lot, PHP, only gets through frameworks where they’ve been added by others.

Adobe, current owners of the official ColdFusion engine, charge rather a lot for licenses and that has a knock on effect on the price of hosting. So, I use Viviotech, who offer the open source engines that run the ColdFusion language. The popular one of those was Railo and is now Lucee. Viviotech recently shifted my sites onto Lucee, which I’d been meaning to try as Railo is old and now discontinued.

I hit a couple of problems:

Gotcha 1: No CGI.PATH_INFO

In the project, I redirect all requests through a single routing file. Within that file, I was using CGI.PATH_INFO to get the path of the page being requested. That stopped working, which turns out to be because the host is using Nginx and that doesn’t have PATH_INFO turned on by default. There are ways of making it work, but I didn’t want to be doing support requests to do that and it may not have been accepted for my cheap-as-chips hosting package.

Instead, I make the redirect in the .htaccess file send the path through for me.

My redirect went from this:
RewriteRule ^(.*)$ ./routing.cfm/$1 [L]
To this:
RewriteRule ^(.*)$ /routing.cfm?path=$1 [NC,L,QSA]
Which gives me the URL of the page being requested in URL.path (apart from the / that is normally at the start, which I needed in part of my URL detection, so I added it on.)

I re-wrote my code to use the new URL.path (with added /) instead of CGI.PATH_INFO and that got it working again.

Gotcha 2: Saving files needs permissions set

In one of the sites, I get an image from an API that makes screenshots, and save it locally so I don’t have to use the API over and over. That means getting the image using CFHTTP, then saving it using CFFILE.

That worked, but I couldn’t open the files. The fix was to use MODE=”644″ within CFFILE. This set the file permissions so the image file can be read by the world, and show up on a web page.

<cffile
action = "write"
file = "<path><filename>"
output = "#cfhttp.fileContent#"
mode="644">

Improvement: Can read SSL protected RSS feeds

Railo couldn’t read RSS feeds that were protected by Let’s Encrypt SSL certificates and some of the other cheap/free SSL providers. Lucee can.

That’s great, as I made a very basic proxy (not really worthy of the word) to go request the SSL protected RSS feed through a PHP script I had on some other hosting, which would then send it through without SSL. Not great for security (although these are all public posts it is reading.) So the update to Lucee let me remove the ‘proxy’, which has simplified my code and maintenance.

Now I have my sites working again, I’m looking forward to delving into Lucee some more.

Fixing Vagrant VMs after a VirtualBox upgrade

I use virtual machines to split up my web development projects. This lets me have a small Linux server run inside my Mac, allowing me to match the operating system with what the code will run in on a public service, without going all the way to running Linux all the time. As I want an easy life when it comes to setting these up, I use Vagrant to make and manage the virtual machines within VirtualBox, which runs them for me.

Recently I set up an extra Vagrant virtual machine (VM) to hold two projects for a client and keep them separate from some of my own projects, as they needed particular settings within Linux and a different database server to run them than the settings and database for my own projects.

I used a Homestead VM, as I knew the settings were good. Homestead is made for Laravel PHP sites, but is perfectly valid for lots of other PHP projects. My client uses various versions of the Symfony framework, and they work fine within Homestead built boxes.

The new VM worked fine but the existing VM stopped working. I could start it, I could SSH into it, but I couldn’t get any websites from it to show in the browser. Which is a big problem, as that’s all it is there for.

After much faff and investigation, I discovered the problem is a bug in the current version of VirtualBox. I had updated it while setting up the new VM, but unlike previous upgrades, this caused a problem. VirtualBox needs VMs to use IP addresses within the 192.168.56.0/21 range or the “bridge” between MacOS and the virtual machine doesn’t work, so no web pages show.

The IP of the old Homestead box my own projects were in was 192.168.10.10, which was the default when I installed it. That used to work, but now does not. The new VM uses 192.168.56.4, which is within the allowed range, so it worked fine.

To fix the old VM:

I had to edit the Homestead.yaml file. At the top where it says:

ip: "192.168.10.10"

I changed it to:

ip: "192.168.56.10"

I then ran:

vagrant reload --provision

To get vagrant to reconfigure the existing Homestead box to use this changed IP address, without deleting anything inside the VM.

And finally I edited the entries in my hosts file (which is in /etc for me in MacOS) for the websites in the VM, changing their IP from 192.168.10.10 to 192.168.56.10

Once all that was done, the websites in the VM started working again.

This was a very, very frustrating problem. I spent a long time investigating what was happening inside the VM as I presumed that’s where the problem was, eventually stumbling on the solution after searching for wider and wider versions of the problem. Thanks to Tom Westrick whose post on Github got me to the solution.