This blog is being hosted by the “WordPress.org” Content Management System (configured for one user) (:1). Yesterday I lost a night’s sleep, trying to figure out why this software was having problems. Tonight, it’s still a little early, for my night’s sleep to start.
Here’s the problem. If we follow the documentation to set up this software, it tries to create a configuration by which the personal contents of a Blog are stored in Linux folder ‘/srv/www’ . This is a tad confusing, because according to other documentation, it could be setting this up in folder ‘/var/lib/wordpress/wp-content’. At the same time, the components of the page which display, that belong to WordPress and its CGI scripts, are set up in ‘/usr/share/wordpress’. The user is given rough guidelines, as to how he can set up his Apache server, to have an Alias according to his configuration file, which points to the General Location from a URL, which is a Parent URL to the one, whose Alias points to the Personal Folders on the hard drive, the latter located under ‘/srv/www’ when the initial confusion is solved.
What can happen next is that the page seems to display in a not-so-neat way, until the owner tries to upload a photo or something, at which point he finds that his browser can no longer even view that file, getting a ‘403-Forbidden’ error. What’s confusing about this situation, is that the user is likely to look very intensely at the configuration file which defines the Virtual Host, or which defines this set of URL-Aliases, as the probable cause fw Apache is not giving access to the browser, to the content folder. This turns into a waste of time, because aside from some semantic quibbles, there’s really no error there.
What happens is that in the Apache configuration folder, there is a Main Configuration File named ‘/etc/apache2/apache2.conf’ . It’s located right next to the files, which tell Apache to create the aliases specific to each Web-site the user has. Under modern versions of Apache, this main config file allows the server – and thus all the pages – to access anything under ‘/usr/share’ and under ‘/var/www’ by default, but explicitly forbids any of the other config files, from accessing other folders, especially ‘/srv’ . This has been put as a security measure, to prevent hijacked Web-sites from doing extensive damage on the host machine. That same config file can easily be edited, to include ‘/srv’ as one of the allowed folders.
But, because none of the troubleshooting attention goes there, it can take time to find this problem. As I wrote, I lost a night’s sleep over this mere annoyance. Once access has been granted to all Apache’s hosted sites, to access ‘/srv’ as well potentially – still according to their own config files – we also see that the page itself displays in its full style and splendor, and that uploaded photos now download to the browser.
There’s a deeper problem with this sort of bug. It can undermine the confidence the user has, in the ability of the provider of the software to program well. I have in fact heard of WordPress, and yet initially, based on the errors I was getting, was not getting a good first impression of it. And the fact that the Style which my Blog displays in, has elements of my personal preferences in it, which were not accessible at first, also made the pages ‘look ugly’ at first, again undermining how well WordPress might be programmed, according to my first experience with it.
This happens often in computing.
And, it also happened too often in my past, that I eventually solved such issues, but that I never left a detailed account to myself, about how I had solved them. Now that I have a micro-Blog, I can rectify this last point.
BTW, Finally WordPress does come across as good software, very functional. And the fact that the software is very functional is confirmed more strongly, by the fact that it was at first even able to display my Blog partially, in spite of not being able to access half its folders.
It’s deprecated under Linux, to store Web content under ‘/srv/www’ !
Edit 01/18/2016 1:) It was only after having installed WordPress.org, and having started my Blog, that I also learned that this package is different from WordPress.com . But this initial gap in my knowledge is of course also tied to the fact, that with the .org product, users “need to get their hands dirty, to make it work”.