Tag Archives: wordpress

WordUp Brighton – WordPress Gems for Devs by Milana Cap

1 Reply

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

Leave a reply

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.

Solving a WordPress update problem on Cloudways hosting

2 Replies

I have several sites hosted on Cloudways, both my own and access to clients ones. I hit a weird problem where WordPress on some sites would update fine automatically or through the admin area of WordPress, but it would not on my own site.

Recently while moving a friend’s site across different parts of my hosting, I found the problem.

Cloudways gives me two levels of SSH account to access the sites on each virtual server. A ‘master’ account which can access the files on all sites and an account on each website which can only access that particular site.

For my own site I hadn’t bothered making an SSH account for it, I just used the master account to upload the files. Not having an SSH account seemed better for security, even though you can turn them off quite easily.

This meant PHP did not have enough permissions to overwrite the files when it came time for WordPress to update itself. For the Farm site, I’d given Haze a website-specific SSH account to upload the files, and that version of WordPress could update itself without issue.

So, I made an SSH account just for my site. Ah-ha, I thought, rather than have to delete the site and re-upload it with the new account, I’ll use ‘chown’ to reassign the files to the user I’ve just created. But… no dice. Something either in their setup or my commands wasn’t working.

Rather than spend even more time faffing, I deleted the site and re-uploaded it using the new details. Now WordPress can update itself with no problems. [Update:] See below for a comment from Mustaasam from Cloudways with how to solve this with a few clicks rather than deleting and re-uploading.

If you’re a Cloudways customer and are having problems with WordPress not updating itself, check how you uploaded the files in the first place. You can do this by using SSH to view the site and ‘ls -la’ to list all the files and which account owns them – if it’s your master account, try deleting the files and upload them again with your site specific SSH account.

Thanks go to Tony Crockford and Matthew Beck for helping me with WordPress and pointing me in directions that eventually lead to me working all this out.