Tag Archives: wordpress

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.

Solving a WordPress update problem on Cloudways hosting

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.