The first thing is to find the path to the theme that you are using, for the default theme the path is:

⁄wordpress⁄wp-content⁄themes⁄default

For other themes the path will vary so make sure you have identified the correct one for the theme you have in use.

Then using your favourite text editor open up the following files:

• functions.php
• header.php

Note: Before you make any changes to these files make sure you have a backup

In functions.php add the following code in an appropriate place.

function list_pages($pages) {
$options = get_option( 'widget_pages' );
foreach ($options as $key=>$value) {
        if ( $pages == $options[$key]['title'])	{
			$sortby = $options[$key]['sortby'];
			$exclude = $options[$key]['exclude'];
        	if ( $sortby == 'menu_order' ) {
				$sortby = 'menu_order, post_title';
				}
			$out = wp_list_pages( apply_filters('widget_pages_args',
					array('title_li' => '',
					'echo' => 0,
					'sort_column' => $sortby,
					'exclude' => $exclude) ) );
        	if ( !empty( $out ) ) {
				?>
				<li><?php echo $out; ?></li>
				<?php
				}
        	}
		}
}

Then add the following line of code in the header.php file. The correct location will vary by theme but generally it will be within the header div.

<ul><?php list_pages('Header1'); ?></ul>

The effect of this will be to list the pages defined by the Pages widget that has a title of Header1, you can edit the the parameter above for list_pages to match the one you are already using. This should work with WordPress 2.8 onwards but probably will not work with previous versions to that.

Fatal error: Cannot redeclare pclziputilpathreduction()

After disabling the WordPress Automatic Update plugin and clicking on the Automatic Update link on the dashboard again the update worked correctly. So that is easily dealt with and not a major problem.

The second problem was more serious, the automatic updates had overwritten the contents of the default theme with the original Kubrick design. If like me you have updated the default or the classic themes but never bothered to create a new theme then WordPress will replace your changed files with the originals.

Luckily in my case there was a backup that I could restore my changes from as I use SVN to store changes to code.

There is a message on the dashboard telling you to backup your files and database before doing the automatic update but many people will ignore this, I know I did!

I guess the moral of this story is to always make sure you have backups of your work before making changes, however tempted you may be to skip this annoying step, and also to create your own theme in WordPress rather than relying on making changes to the default or classic themes as WordPress obviously considers these fair game for overwriting without warning (something the old automatic updates plugin did not do).

⁄wordpress⁄wp-content⁄themes⁄default

For other themes the path will vary so make sure you have identified the correct one for the theme you have in use.

Then using your favourite text editor open up the following files:

• sidebar.php
• header.php

Note: Before you make any changes to these files make sure you have a backup

Next look for the following code fragment in sidebar.php which is used by WordPress to generate the list of page links.

<ul><?php wp_list_pages('title_li='); ?></ul>

Copy the line of code above from the sidebar.php file and paste it in to the header.php file

This will copy the page links from the sidebar to the header. The end result may look strange because of the CSS styles in use. To get the result seen above in the header of this blog I changed the stylesheet to make the page links float right, where you place them is down to personal preferences.

⁄wordpress⁄wp-content⁄themes⁄default

Then using your favourite text editor open up the following files:

• sidebar.php
• header.php

Note: Before you make any changes to these files make sure you have a backup

Next look for the following code fragment in sidebar.php which is used by WordPress to generate the search box (What this code does is to insert the contents of the searchform.php file at this point in the page. The searchform.php file contains the code to produce the search box and the search button).

<?php include (TEMPLATEPATH . '/searchform.php'); ?>

Cut the line of code above from the sidebar.php file and paste it in an appropriate location in the header.php file.

This will move the search form from the sidebar to the header. The end result may look strange because of the CSS styles in use. To get the result seen above in the header of this blog I changed the stylesheet to make the title float left and the search form float right, where you place the search form is down to personal preferences.

The website for this ride was built using Microsoft FrontPage 2003 and looks fine if viewed with Internet Explorer but looks a real mess if viewed with Firefox.

The problem is that FrontPage out of the box has default settings that assume that websites will be viewed with IE. This includes allowing the use of VML Graphics which are the main culprit for things going wrong.
We tried changing the settings on FrontPage and then re-publishing the website but that didn’t improve things at all. The only solution was to create a totally new website then edit the pages manually to remove the VML stuff that was causing Firefox (and other standards-compliant browsers) to go bananas.
As an example of what happens, where content was positioned manually using FrontPage this would be placed in the correct place by VML if the browser was IE. For other browsers there was a jpg image of the content that was displayed instead. The most obvious sign of this happening is where links don’t work when using browsers other then Internet Explorer (how could they as they are just part of an image).
The only sensible solution was to rewrite everything manually removing hundreds of lines of VML. This had the effect of improving performance as the size of the pages is reduced pretty dramatically. Also used CSS to reproduce the table based design of the original website, so FrontPage out of the box didn’t use any CSS at all.
FrontPage 2003 is hardly leading edge these days but there are quite a few websites out there that were built with this tool, and a lot of them have problems with cross-browser compatibility and modern browser standards. With some refactoring work they can be bought up to modern standards without having to re-create them from scratch.

Being new to WordPress I have been using the standard image upload facilities.  After upgrading to WordPress version 2.7 the Flash uploader stopped working so I resorted to using the browser based version. This was annoying but not annoying enough to make me do something about it. Then I noticed that images which were fine when captured looked fuzzy when viewing the published article, specially when using Internet Explorer.

So what was going on? Well, for one selecting anything other than full size meant the images were being re-sized by the uploader and that reduced the image quality, you notice the difference in quality compared to re-sizing the images yourself in Photoshop.

The other thing is that if you select to insert the image at full-size then it will be uploaded at whatever size it is; if that is too wide then the browser will helpfully scale the image to fit within the column. This creates a passable image in FireFox but a pretty blurred image in Internet Explorer.

As an example, the image below has been scaled to fit, in FireFox you can still more or less read the text in the image, in Internet Explorer the image is pretty much unreadable

Right-clicking on the image in FireFox and selecting properties opens the image properties dialog which will show in the Image Dimensions line (highlighted in the image below) that the image has been re-sized

The answer for me was to revert to sizing the images using Photoshop then uploading the images via FTP to the same location as the uploader. Then there is a choice of selecting the image from a URL using the WordPress uploader or just typing in the URL directly to the post. Personally my chosen route is now to do the all the HTML myself, gives me a feeling of being back in control.

The other issue is the number of different images the uploader creates in the WordPress /uploads directory, it seems to create three images at least for every image that is uploaded, hand-rolling the process means you have one image per image in the post and you have control over the process. If you're like me and you keep altering and uploading the image repeatedly then WordPress creates a whole lot of images which become difficult to control and take up loads of space.

The thing that got me writing this article was a question posted on Stack Overflow about data design, asking whether it’s better to use one big table or to arrange the data using multiple related tables.  Having spent many years working with relational databases this seems obvious, it’s easy to forget this is not common knowledge and assume everyone knows this stuff.

The examples below are from a database that contains information about portraits belonging to the University of Oxford.  These portraits are referred to as Works in the database.

The database also holds details of the  people connected to the portraits. This includes the subject of the portrait (the sitter),  the artists who produced the portrait, and others such as donors who have bequeathed portraits to the university.

A portrait may be connected to many people and a person may be connected to many portraits, in other words a many-to-many relationship exists between portraits and people.

There are various ways in which this can be modelled:

• Store the portraits and people in a single table. When several people are linked to a portrait can either have multiple sets of columns to hold the extra people or have multiple rows where the portrait data is repeated
• Store the portraits and people in two separate tables with columns in the portrait tables that hold the links to the various people
• Store the portraits and people in separate tables with a third table to hold the relationships

The problem with the first two solutions above is that data is either repeated or is left empty in case it is required as we can’t know up front how many relationships there will be for each portrait and person.  They are also hard to change when new requirements are identified, e.g. a new type of person needs to be added.

The third solution doesn’t require repeating (redundant) data or booking spaces for relationships that may or may not be required, using data modelling terms we can say it has been normalised.

The extra table by convention is named from concatenating the names of the two tables in the many-to-many relationship, hence the new table in our example is called Work_People as it links the Work and People tables.

The new table is constructed by taking the Primary Key of each of the parent tables. These become the primary key of the new table. In our example both tables have numeric primary keys that are incremented for each new row. Using these abstract keys allows the data in the tables to be changed without having to update the relationships, e.g. the names in the People table can be changed without having to update the Work_People or Work tables.

Note the relationships in the diagram between the three tables.  The connectors that link the tables have a single terminator at the One end of the relationship and have a crows foot at the Many end of the relationship.

There is a One at the One end of the relationship

There is a Zero at the Many end of the relationship.

This is the cardinality of the relationship which means the connector between the Work and Work_People tables can be read as Exactly One row in the Work table can be related to Zero or More Work_People rows.

In other words, new rows can be added to the Work and People tables without having to add relationships to the Work_People table. This allows new works and new people to be added independently of each other,  then the relationships are added as and when required. Note that this isn’t always the case, cardinality will vary and in some cases may specify that the relationships must be added at the same time as the rows in the main tables.

While writing an article on implementing Many to Many Relationships in databases the need for a diagramming tool became clear.  At  work Visual Paradigm is the tool for all UML and data modelling requirements, so it was good to read there is a free community edition that can be downloaded for personal use. The Community Edition page has a link on the left hand-side to download Visual Paradigm.

Clicking  on the round image highlighted in yellow will prompt for registration or a user name and password.  Once you have registered the next page has two checkboxes,  select the second check box to request a license key as an attachment, this will be sent as an email to the address provided during registration.

Then click on the Download button to start downloading the large (140 Mb) executable file.  Once it has been downloaded running the executable will start the installation procedure, you will be prompted for location and so on. When the installation procedure prompts for the product to be installed, make sure you select Visual Paradigm for UML.

The next dialog to be displayed prompts for the edition to be used,  select the Community Edition as that is free for personal use.

The final dialog prompts for the license to be used. Select the Single License Key option and in the file path box enter the path and the name of the license key file that was attached to the registration email.

That pretty much completes the installation. When you first run Visual Paradigm you will be prompted for a workspace which is where all of the diagrams you create will be stored.  Make sure this is set to a path of a location that does get included in backups, particularly if you plan to create diagrams that would be difficult to recreate if they were lost due to a disk crash.

The next part of this article will describe how to get started with  Visual Paradigm and how to create the first Entity Relationship diagram.

How do you make sure your carefully crafted pages don’t fall to pieces when viewed with Safari on Mac OS or collapse in a heap under MSIE 5.0 for Windows?

You can maintain multiple operating systems and perhaps run emulations or virtual machines but it all can be very time consuming and troublesome.

So stumbling across Browsershots seemed to offer a solution to all these issues, you submit your URL and it comes back with screenshots of your webpage for a wide variety of browser and platform combinations.

In their own words what it offers is to:

Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here.

Having used it for a while, and found various horrors lurking in what looked like perfectly viable designs, I can thoroughly recommend this service, and best of all it is free, although if you find it useful you can pay for priority processing. You may have to wait a few minutes for the screenshots to be captured and listed on the page, but that is worth it if like me you don’t can’t afford the various paid services or the cost of having a complete test suite.