tweaks
Related nodes and custom breadcrumbs
21 August 2009 - 17:38Sometimes, having an easy to use CMS like Drupal or Joomla is just one more excuse to keep on tweaking. Just now I added a related nodes block to the article and project pages. Let's say I write an article like this and I tag it drupal. A couple other articles on the same topic are shown in a block in the right column. Hard to do? I don't think so! Just use the views module an some view arguments, like so.
There's more stuff I changed in the last week or so. I completely changed the functionality of the breadcrumbs. I wanted them to reflect the structure I use for clean urls. But I wanted to use page titles instead of the url shorthand (and lowercase) terms. So I created a little snippet. Let's say I have an project with a fairly simple url like /projects/world-domination.
- first I fetch the url and system path
- then I breaks it up in into parts using the / as divider (so I have 3 parts: /, /projects and /projects/world-domination)
- for each part I check if the url is pointing to a valid page.
- for each valid target page I fetch the page title
- then I return all the breadcrumbs with valid links back to the theme
- If the clean url path wasn't found, the normal system breadcrumbs are used as a fallback mechanism
and... Presto! A simple breadcrumb bar for all the project nodes. Including "Home" and the current page's title. Off course I needed to find other solutions for Views, Taxonomy, System paths, etc. but that's a longer (and even more boring) story. I anyone's curious how I did it. I'll send them the code.
Further tweaks
15 August 2009 - 02:49Codeculture.nl just got a bit better. The site was (and still is) in dire need of some tweaks to the interface. There were a couple of problems that needed addressing:
- I wasn't happy at all with the placement of the search box, it just took too much space and broke the flow of the first lines on the front page. Also I wanted to include the search box on every page and remove the search option from the main menu.
- The breadcrumbs looked dull and were hard to read on the striped background under the header.
- I started colour coding the pages with a simple rotator, so you get a fresh look if you refresh the page. However I didn't fully implement this. In the near future I'll probably dump the rotator and use the colour codes to brand specific pages.
- I found the main menu font colour to be a little too light. Click stats affirm this.
- There were some very serious cross browser issues (well, IE issues really, but let's be kind on microsoft for a change). There still are some problems especially with IE7, but at least the site functions properly on all major browsers.
- The project thumbnails on both the project gallery and the project nodes were inconsistent and badly delineated.
SEO and performance
21 July 2009 - 15:46Discussions on Drupal site optimisation are usually technical discussions. But many a time they boil down to philosophical discussions. Search engine optimisation (SEO) and performance tweaks aren't necessarily good for the manageability of your site or for your potential visitors. I ran across a couple of these dilemmas in recent days while trying to optimise my own site.
JS / CSS compression
On of the questions I struggled with is: "should I compress the javascript and css files?". From a performance perspective, the answer is a clear yes. The performance boost is minimal because the servers of my hosting provider have ample headroom. But any performance gain helps. I manage to reduce the number of http requests by 18 simply by combining all the css and js files into 1 file for js and 1 for css. However, because I still do lots of front-end development, I want my own website's css files to be readable by potential clients. If prospects want to judge my css coding skills they'll probably want to take a look at this site's css code to. Compressing the files also makes them very hard to read. And all the care I put into laying out the code neatly (alphabetical element properties, consistent commenting, consistent tagging, etc) is lost for the potential observer. Right now I decided to enable this performance tweak because the potential number of observers is really limited.
Tweaking the site
14 May 2009 - 11:59Since a week I'm working in Haarlem every Tuesday, Wednesday and Friday. With the good folks of 2Value we're manning a new office at the Kenaupark. The synergy of sharing an office location can be a really good thing. One of the benefits is always having a usability guru around. Kor pointed me at some shortcomings of this website. Some of them I solved today. For instance, take a look at the print stylesheets, by making a print preview in your browsers. Looks pretty smart aye? I cleaned up some elements and greatly increased the font size. Another big improvement is the speed of the website. I automatically resize images most images on the size using the the Drupal imagecache module and the GD library. This makes it easy for me to upload full size pngs (my default screenshot file format). However, the file size of the scaled images - the project images and thumbnails - was still way to large. Using some nifty little imagecache actions allow me to change the file format of the images on the fly. Now I cache the images as jpg. This typically saves about 300 KB on the frontpage!