Table of contents.
So. At long last. Three and a half months since I launched my new blog and published my first blog post.
It finally happened.
The one thing absolutely DREADED by anyone and everyone who uses WordPress.
The one thing that will forever HAUNT anyone and everyone who continues to use WordPress till the end of time.
An update broke my WordPress website!
The good news is, I got lucky. It only broke something minor in the WordPress editor, and did not cause any critical or major failures. I didn’t even notice anything was amiss until I updated one of my blog posts about two hours ago:
Whenever I hit “Update” to save changes to my blog post, an “unexpected error” dialogue would always appear as shown in the above screenshot. Fortunately, the changes I made were still being saved and displayed properly on my website.
Phew! It’s not all bad. I could work with that.
But the error meant that I cannot continue editing the blog post after each save. I had to reload the “Edit Post” page over and over again to make further changes.
And that got on my nerves real quick.
Finding the root of the problem.
The “unexpected error” dialogue provided me with the option to “Copy Error”. So I pasted the contents of the error into a text editor, and this is what I find:
TypeError: (0 , b.useId) is not a function at tm (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/components/index.min.js?ver=c2165e5c3ae766fe35c4:1:243490) at ft (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:43415) at as (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:111109) at Fr (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:77616) at Dr (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:77544) at Rr (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:77407) at Nr (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:74402) at https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:30158 at unstable_runWithPriority (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react.min.js?ver=6.1.1:1:7431) at xn (https://scatteringclouds.com/wp-content/plugins/gutenberg/build/vendors/react-dom.min.js?ver=6.1.1:1:29935)
Since /wp-content/plugins/gutenberg/ is plastered all over the above error message, the issue is likely caused by the Gutenberg plugin.
A quick Google search using the first line of the error message “TypeError: (0 , b.useId) is not a function” led me to a fresh Github issue, where a number of users have also encountered the same problem with Gutenberg version 14.8.0.
The Gutenberg plugin is a beta plugin for the WordPress Gutenberg editor, and it contains experimental “bleeding-edge” features that are currently under active development. In other words, the plugin is constantly getting new updates, and each update might introduce website-breaking changes at any given time.
The Gutenberg plugin requires such frequent updates that I simply stopped caring. I hit the “Update Plugins” button whenever it comes up just to get rid of the prompt in my WordPress admin dashboard.
Three months later, it finally came back to bite me.
But I don’t want to disable the plugin, because I am still using its experimental “Table of Contents” block in my blog posts! I need a way to continue using the Gutenberg plugin without it causing errors when I edit my blog posts.
Surveying my options for repair.
There are a few ways I can fix this problem without disabling the Gutenberg plugin.
The opportunistic fix: Replacing the plugin with an older version.
Since I managed to identify the plugin causing the issue (Gutenberg), and the rest of my website remained fully operational despite the error, I can fix the issue by
- visiting the advanced view of the plugin on the WordPress repository,
- download the most recent working version prior to 14.8.0, which in this particular case is version 14.7.3,
- bring up the “Plugins” page on my WordPress admin dashboard,
- remove Gutenberg 14.8.0,
- upload and install Gutenberg 14.7.3,
- and wait for a proper fix in a future update, which arrived in Gutenberg 14.8.1.
However, if an update causes a fatal conflict that took down my website for good, I might not even be able to identify which update caused the issue.
I would have to work out what caused my website to fail, navigate through my WordPress directory using the file manager provided by my hosting control panel, and figure out how to replace the problematic plugin (or theme) files manually.
Things can get rather hairy at this stage, and I could cause more harm than good if I replaced the wrong files in the WordPress directory.
I could ask for help from my website hosting company, but I would have to wait for their support. And if their support staff are unable to identify a fix, they would most likely resort to restoring my website using automated server backups.
The last resort: Automated (server) backups with my website host.
Good website hosting companies will provide you with automated server backups on a daily basis. Some will keep the backups for 7 days, some 14, some may go up to 30 days or more, and some may even offer hourly backups for an added fee.
I went into further detail on why it is best to have a host that backs up your precious website every day for at least the past fourteen days in a previous blog post.
However, restoring my website to a previous server backup is usually the last resort. Because I would lose all the latest edits and changes I have made to my website – between now and whenever the daily automatic backup decides to kick in.
And if the backup from the previous day failed to fix the issue, I would have to try even older backups from two days prior, which leads to more work being lost.
And so on, and so forth. If I’m unlucky, the issue might persist until I have exhausted all previous server backups for the past week or month. In which case, I might have to salvage what I can and rebuild my entire blog from scratch.
Definitely not a fun prospect to have.
The old reliable: Fine-grained restoration using my own website backups.
The core WordPress software does not come with any backup facilities by default. But you can find plenty of free and paid plugins in the official WordPress repository, which can be used to add backup and migration features to your WordPress site.
This is one of the main reasons why I chose to build this blog using WordPress in the first place: TRUE ownership and control of my own website.
I get to create, automate, and even download my own website backups in WordPress, all with a few simple clicks. No technical knowledge required at all!
With those backups, I can easily restore or migrate my blog to an entirely different website host. A good backup plugin will allow me to revert a part of my website (e.g. a bad theme or plugin update) while leaving everything else unchanged.
Bonus: My plugin of choice for website backup and migration.
As of the writing of this article, the free plugin allows you to create and upload your backups to cloud storage services like Dropbox, Google Drive, Microsoft OneDrive, Amazon S3, and DigitalOcean Spaces, along with support for SFTP and FTP.
The pro or paid version of their plugin adds support for additional cloud storage solutions like Wasabi, pCloud, and Backblaze, with more options coming soon.
I currently use the pro version to automatically upload website backups to my pCloud account. This plugin has saved me a lot of trouble in the past, when my previous website host got hacked and their servers were wiped clean.
The pro version also comes with a very useful feature: It automatically creates a lightweight “rollback” backup of my WordPress plugins, themes, or WordPress core files, as well as my entire website database before anything gets updated.
So if something goes wrong, I can quickly restore everything back to normal with a few simple clicks, which I will demonstrate in the next section.
Note: If a bad update causes a fatal conflict that brings down my entire site, then WPvivid’s lightweight “rollback” backups will not be of much use, since I would not be able to access my WordPress admin at all.
In this case, I would have to restore my blog from a full website backup. The restoration process will take longer and be a little more involved than rollbacks.
You can create full website backups using the free version of WPvivid, and the backup files can be downloaded to your own computer for safekeeping.
A good website host should also be able to provide daily server backups, which can be used in place of full website backups to try and restore a broken website to a former working state. However, if your host goes down, you will also lose access to their server backups, so it is not something you should ever count on.
Rolling back a bad update.
This is how I use the paid version of WPvivid pro [affiliate link] to revert the bad Gutenberg plugin update from 14.8.0 back to 14.7.3.
Select the right backup.
All I really need to do is to navigate to the “Backups & Restoration” section of WPvivid’s pro dashboard and find the most recent backup of the type “Rollback”, and then click on the “Restore” option circled in red in the screenshot below.
In my case, the most recent “Rollback” backup is automatically labelled with the comment “gutenberg”, so it is fairly trivial to determine which backup to choose.
Side note: You will notice two types of backups in my dashboard.
- Rollback backups are automated, smaller in size, and faster to restore from.
- Manual backups consists of a full copy of my website – a complete backup.
These complete backups are created manually by me, so I can upload a copy of the current version of my website to cloud storage for safekeeping.
Since my blog is still quite small, and I am the only one editing its contents, I have opted to back up my websites manually. In the future, I may also set up automated backups that uploads a full copy of my website to the cloud daily.
Reverting the problematic Gutenberg plugin.
The “Restore” option brings me to the following page:
Simply click on the button labelled “Next Step” to move past step 1. In step 2, simply uncheck all options except the one labelled “gutenberg”, which is the plugin we wish to restore, and then click on the button labelled “Restore Now” as shown in the screenshot below.
Which brings us to step 3: Congratulations! If everything goes smoothly, the problematic Gutenberg plugin will be reverted to a previously working version.
I can verify that my Gutenberg plugin had been reverted by going back to my WordPress admin and clicking into the “Plugins” page.
I have taken a screenshot of the Gutenberg plugin entry as shown below, and we can see that the current version of the plugin has indeed reverted to 14.7.3.
And thus, with a few simple clicks, my WordPress website is now brought back to full working condition. How easy is that?
Since I built my website with WordPress, I can easily prepare for the unexpected and cover my own ass when disaster strikes. My current host can go down at any time, and I can still bring my sites back up on a different host with relative ease.
You don’t get to do that with all-in-one builders like Squarespace, Webflow, or Wix.
These website builders are far too intent on locking down and trapping their users into a proprietary ecosystem to care about such meagre trivialities. Who cares if their users have no emergency backup plan in the event of a catastrophic failure?
Sure, some website builders may allow you to export a part of your website, or even export a full, static copy. But good luck reconstructing a functioning website from those exports when you lose access to your Squarespace, Webflow, or Wix account!
Of course, since I took on the responsibility to back up my own websites, there are still a number of things I need to look out for.
- Backup operations can be resource intensive and take a lot of time to complete. Your website host might have timeouts set in place to kill any processes deemed to be creating excessive load on their servers, causing your backups to fail.
- The backup file might become damaged or corrupted, making it impossible to restore a website properly. This is why I keep on insisting that an untested backup is NOT a valid backup. Always check your latest backups at regular intervals using a staging site.
At the end of the day, your website is your own responsibility. If your livelihood depends on it, you better make damn well sure your backups are up to snuff.