Weekly update #12

Days worked this week: 4

- Aligning search box/menus on the Home page, as well as adding and removing some panels/graphics to tidy things up in time for the launch.

- Upgrading Panels 2 to Panels 3, (along with Chaos Tools, which is required to do this). Panels is one of the main modules I use, and upgrading to the new version was recommended to me. However, I was uber careful about doing this, as I gathered from the page on upgrading from Panels 2 to Panels 3 (http://drupal.org/node/515140) that doing so can be buggy. So I backed up absolutely everything, as I wasn't sure which data was stored in the database. For example, some of my panels just contain HTML code, so I carefully copied this out from each panel and pasted into a text editor. The update went pretty smoothly as it happens, and HTML panels required no effort on my part.

The only things that did change were:

• the css must be different for some things in Panels 3, as certain things on my homepage moved around and lost their styles. This was easily fixed having investigated what had happened using Firebug, and I changed my css code to reflect these updates
• The slightly annoying thing about Panels 3 (which, like Panels 2 uses the 'Pages' interface), is that the interface now tries to fit into the width of my website (which has a fixed width). This width isn't wide enough for the Pages interface to display some of my panel pages when I'm editing them, so I have to switch back to the Garland theme before I can edit things in Panels.

I also found a bug when clicking on the dates in the 'Events' section I have on my homepage. Googling this shows many others have had the same problem since upgrading Drupal core, and it relates to comments. This is the error I was getting:

user warning: Unknown column 'u.signature_format' in 'field list' query: SELECT c.cid as cid, c.pid, c.nid, c.subject, c.comment, c.format, c.timestamp, c.name, c.mail, c.homepage, u.uid, u.name AS registered_name, u.signature, u.signature_format, u.picture, u.data, c.thread, c.status FROM comments c INNER JOIN users u ON c.uid = u.uid WHERE c.nid = 87 ORDER BY c.thread DESC LIMIT 0, 50 in...

Fortunately, some kind person named 'maximum' has shown how to fix it. It goes as follows:

• Run update.php
• This includes a dropdown menu entitled 'Select versions'
• From this dropdown, select 'System module' then '6051'
• This has fixed the error for me, and many others

Weekly update #11

Days worked this week: 1.3 Days

Due to holiday/other work commitments, I've not worked on the website for a couple of months now, so was relieved to see that the me of two months ago had kindly written some notes for the me of today, on the kinds of things I'd have forgotten about while away.

Before I could even start reminding myself how Drupal worked and carry on working on the site, I was stumped at the first hurdle* when I discovered Drupal's dreaded White Screen of Death (WSOD) on the Modules page (admin/build/modules) for my site.

I spent about a day trying to fix this, and found this page on the Drupal site to be particularly useless, given that its first solution to 'admin/build/modules' giving a blank page involves going to 'admin/build/modules' and changing some settings. How on earth are you meant to do that if it's blank?!

I've had this problem before and it's usually fixed by running update.php (which is done by visiting 'http://www.example.com/update.php' , where 'www.example.com' is changed to the URL of your website), as well as running Cron (which you can do from www.example.com/admin/reports/status). This normally magically fixes problems like this, but that wasn't making any difference. I'd also increased the PHP memory limit to 96MB, as recommended on this page and this one, which aside from the flaw mentioned previously, seemed to be the most knowledgeable Help pages on this error. This hadn't fixed the problem either, so I was starting to worry.

Fortunately a friend of mine knows his stuff when it comes to Drupal, and worked out what the problem was within minutes. He worked it out by viewing the error log in MAMP, which is what i'm using on my Apple laptop to run the laptop as a virtual server while I develop the site. To find this log, you'll need to navigate somewhere like here in Finder (if using OSX) - not sure where it would be if in Windows:

Applications>MAMP>logs>php_error.logs

Right-click that .logs file and open in 'Console' (not sure what the Windows equivalent is. possibly 'Terminal'?). Once Console has fired up, you may need to navigate on the left side of it to the 'php_error.log' file. The errors shown here are shown in order of date and time, so scroll around until you find the time you tried looking at the Modules page to find it blank. In this particular case I was getting the following message:

PHP Fatal error: Only variables can be passed by reference in /.../.../.../.../sites/all/modules/admin_menu/admin_menu.inc on line 536

[I've edited that error message slightly to remove irrelevant bits of the address, that relate to where specifically on my computer the file path is]

This gave the clue that the Administration Menu Module (or 'admin menu' as it's sometimes referred to), was causing problems. Indeed, when temporarily moving the 'admin_menu' folder out of my 'sites/all/modules' folder (which is where you should be keeping your modules), I could then access the Modules section on my website, so problem solved!

When I say 'problem solved', of course it's not entirely. Although the Administration Menu Module isn't essential for site development, it is one of the most useful modules out there, and I'm now left without it. Looking at their web page, it looks like there's a general problem with this module that I don't think is their fault, so here's hoping that gets fixed soon.



*Am I mixing two sports there, cricket and horse racing, or is that a real phrase?