Adventures & experiences in contemporary technology
Putting this blog back on its feet after a spot of web hosting bother caused me to learnt a bit more about web hosting than I otherwise might have done. Here’s a selection and they are in no particular order:
I know that that there better things to call a blog post than to use part of an error message that I got from Saxonica‘s Saxon while I was converting XML files into PHP equivalents for the visitor information section of my main website. I use the open source Saxon-B rather than the commercial Saxon-SA and it fulfils all of my needs and version 8 and later (it has now reached 9.0.0.2) handle the XSLT 2.0 features that I need to make the transformations really clever. Also, because Saxon is available as a jar file, it is cross platform so long as you have Java on board. There are, however, some slight differences in behaviour. I now run thte thing in Linux and any Windows-style file locations are not recognised. I had the file path in a DTD declaration starting with "J:\" and that was thought to be a protocol like file, http, https, ftp and so on because of the colon. There’s no j protocol so Java gets confused and, voilà!, you get the rather obscure error that titles this post. Otherwise, the migration of the Perl script that creates XSLT files and fires off the required XML to PHP transformations was a fairly straightforward exercise once file locations and shebang line were set right.
Installing all of the bits and pieces is painless enough so long as you know what’s what; Synaptic does make it thus. Interestingly, Ubuntu’s default installation is a lightweight affair with the addition of any additional components involving downloading the packages from the web. The whole process is all very well integrated and doesn’t make you sweat every time you to install additional software. In fact, it resolves any dependencies for you so that those packages can be put in place too; it lists them, you select them and Synaptic does the rest.
Returning to the job in hand, my shopping list included Apache, Perl, PHP and MySQL, the usual suspects in other words. Perl was already there as it is on many UNIX systems so installing the appropriate Apache module was all that was needed. PHP needed the base installation as well as the additional Apache module. MySQL needed the full treatment too, though its being split up into different pieces confounded things a little for my tired mind. Then, there were the MySQL modules for PHP to be set in place too.
The addition of Apache preceded all of these but I have left it until now to describe its configuration, something that took longer than for the others; the installation itself was as easy as it was for the others. However, what surprised me were the differences in its configuration set up when compared with Windows. Same software, different operating system and they have set up the configuration files differently. I have no idea why they did this and it makes no sense at all to me; we are only talking about text files after all. The first difference is that the main configuration file is called apache2.conf in Ubuntu rather than httpd.conf as in Windows. Like its Windows counterpart, Ubuntu’s Apache does uses subsidiary configuration files. However, there is an additional layer of configurability added courtesy of a standard feature of UNIX operating systems: symbolic links. Rather than having a single folder with the all configuration files stored therein, there are two pairs of folders, one pair for module configuration and another for site settings: mods-available/mods-enabled and sites-available/sites-enabled, respectively. In each pair, there is a folder with all of the files and another containing symbolic links. It is the presence of a symbolic link for a given configuration file in the latter that activates it. I learned all this when trying to get mod_rewrite going and changing the web server folder from the default to somewhere less susceptible to wrecking during a re-installation or, heaven forbid, a destructive system crash. It’s unusual but it does work, even if it takes that little bit longer to get things sorted out when you first meet up with it.
Apart from the Apache set up and finding the right things to install, getting a test web server up and running was a fairly uneventful process. All’s working well now and I’ll be taking things forward from here; making website Perl scripts compatible with their new world will be one of the next things that need to be done.
There seems to be a percolation of plugins that aim to change the appearance of WordPress administration pages from their day-glow blue to something more pleasing; Earthtones is the one that I use for this blog but I have also been known to use WP Tiger Administration as well. Both options work well, though the latter needs some adjustments to work as well with WordPress 2.3 as it does with the 2.2 line. One area that they both fail to influence is the appearance of the upload screen. It doesn’t help that upload.php, the underlying PHP script, is a dual purpose animal: used in an iframe in the post editing page and standalone for upload management. Curiously, you can only upload files on the post editing page and not on the upload management screen, a definite quirk. The thing that really stops these admin theme plugins gaining any sort of purchase with upload.php is that it also uses an auxiliary stylesheet, upload.css, that is called after the WordPress function hook has been defined; if it came before this, then the styles in upload.css could be overridden. You could edit upload.php and edit the replacement stylesheet but the former activity would require repeating at every WordPress upgrade. I chose to edit upload.css and will keep that is a safe place so that I can replace the file following an upgrade. If upload.php was treated like every other admin script, then this would be unnecessary. A useful suggestion for Automattic, perhaps?
I was ambling around the web and came across a website that, while it appeared to be a blog, isn’t one in the vein of that to which we are accustomed. It does, however, have a blogroll and that is where Blogrolling.com comes into this piece. Blogrolls are very much a feature of the blogging (WordPress call them that anyway) world and act as a repository of useful links relevant to the subject of the blog. I also use them as a bookmarking station for myself and a way to return the favour when someone links to my blog. For a blogroll, you generally need a database sitting behind in the background or you end up creating a list of links in (X)HTML.
Blogrolling.com offer another option: placing your links at an external website and including them on your webpages using a piece of code to pull in the information. RSS, JavaScript and PHP are among the methods on offer from Blogrolling.com; I used PHP when I gave the service a whirl on one of my offline blogs and that really does give you a lot of customising power over and above using CSS. That’s not to say that there aren’t customisation functions on offer from Blogrolling.com, I found a few of these distinctly useful: ordering of links in a blogroll is just one. When it comes to categorising your links, you don’t get the category option but you do get to create as many blogrolls as you want so there is a workaround; moving links from one blogroll to another is mouse intensive but straightforward. Also, because you are reading each blogroll in turn, you have the ability to order the categories as you want them. With WordPress’ category approach, ordering categories involves widgets and plugins or getting your mits dirty with some code cutting. All in all, Blogrolling.com seems to offer an intriguing and useful service.
I got the idea recently that I’d upgrade a feedback form that I have on my photo gallery so that it would email me me comments left by visitors rather than just storing them on the web server for later perusal. I opened up my copy of PHP Unleashed (John Coggeshall, SAMS), turned to the relevant chapter and it all started to look rather daunting. Then, another suggestion popped into my head: potter over to PEAR and see what they have there. In the light of my reading, I knew what I wanted and downloaded the Mail and Mime-Mail packages. Another spot of perusal led me to some sample code that I could use with these and I modified that to suit. Within 30 minutes, the results of my labours were in place and it all works very nicely too. I still need to learn more about the code that I am using, though.
The Login Logger WordPress plugin sounds a great idea and it works fine with standard situations. However, go beyond these and things start to go awry. An example is where you have to use unique database table prefixes because you use shared hosting. This is certainly something that I do and it breaks Login Logger. Thankfully, the fix for this is easy enough: just amend the database query on line 22 in the manage.php file as follows:
Before:
$query = “SELECT distinct wp_users.user_login,”.$table_name.”.username FROM wp_users LEFT OUTER JOIN “.$table_name.” ON wp_users.user_login = “.$table_name.”.username WHERE “.$table_name.”.username IS NULL”;
After:
$query = “SELECT distinct ” . $table_prefix . “users.user_login,”.$table_name.”.username FROM ” . $table_prefix . “users LEFT OUTER JOIN “.$table_name.” ON ” . $table_prefix . “users.user_login = “.$table_name.”.username WHERE “.$table_name.”.username IS NULL”;
The issue was caused by hard-coding of the table prefix for the user table and using the prefix that you yourself have set is the way out of this. What is less easy to resolve is a conflict between Login Logger and the Themed Login plugin. That will take further investigation before I come up with a fix.
When I wrote about tidying dynamic URL’s a little while back, I had no inkling that that would be a second part to the tale. My discovery of mod_rewrite, an Apache module that facilitates URL translation. The effect is that one URL is presented to the user in the browser address bar, and the exact same URL is also seen by search engines, while another is passed to the server for processing. It might sound like subterfuge but it works very well once you manage to get it set up properly. The web host for my hillwalking blog/photo gallery has everything configured such it is ready to go but the same did not apply to the offline Apache 2.2.x server that I have going on my own Windows XP box. There were two parts to getting it working there:
Once you have got the above sorted, adding this line to .htaccess: RewriteEngine On. Preceding it with an Options directive to ensure that FollowSymLinks and SymLinksIfOwnerMatch are switched on does no harm at all and may even be needed to get things running. That done, you can set about putting mod_write to work with lines like this:
RewriteRule ^pages/(.*)/?$ pages.php?query=$1
The effect of this is to take http://www.website.com/pages/input and convert it into a form for action by the server; in this case, that is http://www.website.com/pages.php?query=input. Anything contained by a bracket is assigned to the value of a system-named variable. If you have several bracketed sections, they are assigned to sequentially numbered variables as follows: $1 for the first, $2 for the second and so on. It’s all good stuff when you get it going and not only does it make things look much neater but it also possesses an advantage when it comes to future-proofing too. Web addresses can be kept constant over time, even if things change behind the scenes. It means that returning visitors will find what they saw the last time that they visited and surely must ensure good karma in eyes of those all important search engines.
A few years back, I came across a very nice article discussing how you would make a dynamic URL more palatable to a search engine and I made good use of its content for my online photo gallery. The premise was that URL’s that look like that below are no help to search engines indexing a website. Though this is received wisdom in some quarters, it doesn’t seem to have done much to stall the rise of WordPress as a blogging platform.
http://www.mywebsite.com/serversidescript.php?id=394
That said, WordPress does offer a friendlier URL display option too and you can see this in use on this blog; they look a little like the example URL that you see below, and the approach is equally valid for both Perl and PHP. I have been using the same approach for the Perl scripts powering my online phone gallery and now want to apply the same thinking to a gallery written in PHP:
http://www.mywebsite.com/serversidescript.pl/id/394
The way that both expressions work is that a web server will chop pieces from a URL until it reaches a physical file. For a query URL, the extra information after the question mark is retained in its QUERY_STRING variable while extraneous directory path information is passed in the variable PATH_INFO. For both Perl and PHP, these are extracted from the entries in an array; for Perl, this array is called is $ENV and $_SERVER is the PHP equivalent. Thus, $ENV{QUERY_STRING} and $_SERVER{‘QUERY_STRING’} traps what comes after the “?” while $ENV{PATH_INFO} and $_SERVER{‘PATH_INFO’} picks up the extra information following the file name (the “/id/394/” in the example). From there on, the usual rules apply regarding cleaning of any input but changing from one to another should be too arduous.
Ever since I converted it from a client-side Javascript-powered affair, my online photo gallery has been written in Perl. There have been some challenges along the way, figuring out how to use hash tables has been one, but everything has worked as expected. However, I am now wondering if it is better to write things in PHP for sake of consistency with the rest to the website. I had a go a rewriting the random photo page and, unless I have been missing something in the Perl world, things do seem more succinct with PHP. For instance, actions that formerly involved several lines of code can now be achieved in one. Reading the contents of a file into an array and stripping HTML/XML tags from a string fall into this category and seeing the number of lines of code halving is a striking observation. I am not going to completely abandon Perl, it’s a very nice language, but I do rather suspect that there is now an increased chance of I having a website whose server-side processing needs are served entirely by PHP.