Hey everyone Patrik CK here with a solution to a problem that I recently started experiencing
when working on my WordPress.
I noticed on several different sites after saving the same page many times the process
of saving was taking longer to complete.
It got to the point where on occasion it wouldn’t save at all.
I thought to myself that this can’t be a server issue since I have a beafy dedicated
server with plenty of horsepower, RAM, and an optimized OS.
So I installed a database optimizing plugin called WP Optimizer on one of the websites
that was experiencing the issue and noticed something intriguing.
Among the list of items the plugin looks to optimize and cleanup are page revisions.
It showed that there were 453 saved revisions in the database, which needless to say sounded
a bit high, considering this site only had 7 main pages including the homepage.
After thinking about it for a second though I actually wasn’t surprised there were that
many revisions.
One reason for this is whether you’re using say Elementor, Beaver Builder, Divi, or really
any of the advanced page builders, making quick page updates is so easy you lose track
of how often you actually hit that update button.
I mean when it takes literally 6 seconds to open the front-end editor, update something,
and save it, it’s no wonder there are a tone of saved revisions.
So why is this a problem?
Well to answer that we have to take a little trip into the bowls of a website, into the
database and the fundamental tables that make up the WordPress core.
Page revisions are saved with the page/post meta data in a table called postmeta.
The more revisions you save the larger this table gets.
In the site I mentioned with 453 saved revisions, this single table grew to over 246 megabytes.
Just for comparison this same table on a completed site with 12 pages and around 30 posts that
doesn’t use an advanced page builder is only 24 megabytes, a significant difference.
MySQL database tables simply should not be that big because it introduces a host of issues.
One of those issues is the one I introduced at the beginning, saving pages with a tone
of revisions can taking longer to process after an update.
Another issue comes when you are trying to deploy a development site, which I personally
ran into when trying to update the URLs to the live domain, my search and replace kept
hanging when it hit the post_meta table.
So how do we fix this?
One obvious solution is just to use the WP Optimize plugin to flush out all the revisions
every once in a while.
But this has a couple draw backs.
Mainly it’s a manual process and when you have multiple people working on a site it
can still get out of hand quickly, also you’ll be wiping out all of the revisions which someone
may need.
So we need a solution that’s automated and keeps some revisions available for users who
may need them.
Luckily there is an incredibly simple solution that takes only one line of code to implement.
Deep in the WordPress development documentation there is a little piece of code that limits
the numbers of revisions saved to a specified amount.
By default WordPress will save unlimited page revisions.
This code accomplishes exactly what I wanted.
Here it is: Yep, that’s it and it goes into your wp_config
file.
Simply swap out the X for the number of revisions you want to save or set it to 0 to save no
revisions at all, which may be suitable for some.
For me I set it to 12.
I feel it’s a good balance between still having some revisions to work with without
going overboard.
One peculiar thing about the code is that it only seems to work when added near the
top of the wp_config file.
If you add it at the bottom it doesn’t work for whatever reason.
Another thing to take into account is that simply adding the code to an existing site
will not remove old revisions.
It will just show however many revisions you specified when editing a page or post.
You’ll still need to run the WP Optimize operation to flush out all the saved revisions
to decrease the size of the database.
If you don’t have access to your wp_config file there is just as simple a code that can
be added to the functions.php file.
I prefer for the former method for several reasons, but mainly since the functions.php
file is tied to your theme if you change the theme and forgot to add the code you’ll
go back to saving all revisions again.
Whichever way you go it’s a world of difference especially if you are tasked with website
or server maintenance like myself.
After implementing the code the post_meta table stabilized around 54mb without adding
new pages/posts, a much better situation than before.
The saving issue was also resolved on every site where I flushed the revisions and then
implemented the code.
It hasn’t been a problem since I standardized the code for every new development site I
create.
You can find both pieces of the code on my website at the link in the description.
I hope this small tip helps you all out with your development work.
If you found this video helpful please leave a like and consider subscribing to get future
videos.
Until next time this has been Patrik CK, good bye.