Warning: Extreme Web geek talk ahead!
Well, at the time of the last post I thought I had everything on our website working again, but I was wrong. There appears to be a bug in WordPress (which has nothing to do with our server change) that, if the link name for the post happens to start with the prefix of the path of the blog URL, the article cannot be found using its permalink. The URL to our blog is https://www.papertrail.ca/blog, so in the case of recent posts about the blog being broken and then fixed, whose link names are, for example, blog-fixed (so the full URL to the post is https://www.papertrail.ca/blog/index.php/blog-fixed), the WordPress code looks for a page whose link name is -fixed rather than blog-fixed (and fails to find it).
I worked around the problem by manually changing the the link name (“slug” in WP parlance), which is generated from the post title, from blog-something to xblog-something.
This had not been a problem previously because our old permalinks looked like https://www.papertrail.ca/blog/blog-fixed, which includes the post date. The page link always starts with a year number which can never be equal to the blog path.
I tried searching the WP problem database but could not get a sufficiently specific search to determine if this was a known problem.
I also changed our static web pages (outside WP land) from XHTML to HTML5 because our new server can’t insert charset= modifiers into the Content-type HTML headers of the web request replies. The old files had the encoding in the <?xml ... ?> header but this was being ignored because the browser content-type was text/html rather than application/xhtml+xml. I could have fixed it by changing all the files to .xhtml extensions but I would have had to change all the internal links as well. Instead I removed the <?xml ... ?> header, added a <meta charset=.../> and changed the <!DOCTYPE from XHTML to <!DOCTYPE html> which implies HTML5.
Speaking of changing links, WP has another oddity. When you define things like menus, you can make the menu items link to a WP post, a WP page, or a “custom” link which is just a fixed URL. When you change the permalink format on your site options, the menus that link to posts and pages automatically produce the referenced URL in the new format. On the other hand, when you link from the content of one post or page (or comment) to another post or page, the link is always a fixed URL that does not change when the site’s permalink format is altered. The only way to correct this is to modify all the post, page, and comment text to change the URL in the links. I will eventually do this using a direct query to the underlying MySql database, but in the meantime, I have the web server configuration set to redirect old permalinks to the new permalink format using a 302 status. This will also benefit people who have their own bookmarks or links to specific articles.
As for the reason for all these changes, the system that hosts our web site has recently been upgraded from an unsupported old release of OpenBSD to a more recent one to ensure we could be up to date on security fixes. We had been using Apache as the web server program, but this is no longer available for OpenBSD. For a while the maintainers flirted with Nginx as a web server, but they also dumped that and went with a basic httpd that is very sparse in terms of configuration options.
Leave a Reply