WordPress problems
A quick post to report a couple of problems that cropped up after an overnight update of WordPress (on which this site is based).
First a serious fault.
The site’s home page failed to appear – instead throwing up a 404 (page missing) error. This occurred whether the plain site URL (https://www.biznik.co.uk) was entered into a browser or the Home menu link was selected. No change had been made to the page or the site
The home page has a permalink when initially created but when you choose a Static Page as your home page WordPress removes the normal permalink edit option and stores the page address internally in order to perform the redirection. After the update (to WordPress 5.6.2) something had broken this link.
I first checked the home page permalink setting. To do this go to Settings -> Reading and change the “Your homepage displays” setting from “A static page” to “Your latest posts”. Then go to the Pages section of the main menu. My intended (original) home page status was still showing “Front Page” nevertheless I clicked to edit the page and checked the Permalink setting … which also remained unaltered.
So, I made a small change to the page and re-published it.
Head back to Settings -> Reading and change back to a static page and the correct Posts Page, save and check. No difference – any attempt to call up the site’s home page threw a 404 error.
My solution was to:
- Copy the entire content of the original home page
- Return to the Pages section and delete the page
- Create a new page, change to the code editor view (Ctrl-Shift-Alt-M or use the hamburger menu) as the copied page contents are in plain HTML format
- Paste the copied page contents into the page
- Change to the Visual editor
- Convert the page to Blocks to use the Gutenberg editor
- Edit the Permalink in the Post section of the right-hand options bar to be the same as the original permalink
- Return to Settings -> Reading and select the new page as the desired home page.
Voila (as my neighbours say). The home page magically reappeared and redirection via all mechanisms worked once more.
Second the Site Health plugin
that first appeared in WordPress 5.2 reported
A plugin has prevented updates by disabling wp_version_check()After searching the web for quite a while the general advice seemed to be to disable all installed plugins (except the Site Health plugin of course) and then re-enable each plugin one-by-one and re-checking Site Health until the one that is causing the problem shows up.
Problem: The error message remained even with all plugins on the site deactivated. Further research found that there is a PHP static definition WP_AUTO_UPDATE_CORE that must be set true before the Site Health plugin will work,
A quick grep of the entire site contents showed that this static was not being set anywhere. The solution (quick & dirty and I only hope the WordPress developers get round to a fix at some stage – though this should do no harm even if left in place) is to edit the file wp-config.php which is found in the root of the website directory and add the lines:
/** Force definition of WP_AUTO_UPDATE_CORE **/
define('WP_AUTO_UPDATE_CORE', true);Maybe I missed a notice issued with an upgrade but I would assume that a developer would install an essential setting on installation or update of new code. Ho hum – problem fixed for now.
Conclusion
WordPress like any piece of large, complex software can be described as “fragile”. What do I mean? Where commercial software is (or should be!) tested to death before a new release is issued open source or collaborative projects in general are developed by a veritable army of people and, before long, there exists the software equivalent of a bowl of spaghetti – impossible to test as will be realised as soon as you understand just a couple (of many) problems
- Any software project as “flexible” as WordPress – with a huge range of contributed themes and plugins and vast possibility of combinations – cannot be tested centrally. It simply is not possible to assemble every possible combination of core project and connected add-ons.
- Ensuring that plugins/add-ons/themes remain compatible with new versions of the core cannot be undertaken by the core developers. The best they can do is require that the external developers test their contributions with any new release and “certify” compatibility with a new release. Best not to talk about retaining compatibility with older releases at this point.
In short, the only realistic way a given implementation (ie; collection of core project plus whatever themes / plugins / add-ons / extensions have been installed) can be tested is in the hands of the user of that specific installation. It is therefore the user’s responsibility to test their implementation of software continues to operate as expected when any change occurs.
Of course, everyone is busy these days and many software users do not have the luxury of a team of people sitting around just to test some large, complex piece of business-critical software. In fact many software developers (of which the good folks at WordPress are one) make it easy to keep an installation up-to-date by offering an automatic update option.
Automatic options are attractive in these days of Internet exposed systems and ever-changing threats and new exploits becoming discovered. On this basis – no-brainer – auto-update away.
Just remember your responsibility to test after each and every update or configuration change that occurs.