A Journal by a James

Bugzilla Thoughts

Bug reporting is tricky. Bugs are problems in software where the software doesn’t work as it should. “It doesn’t work.” doesn’t get you anywhere with the developer of the software in question, so the key is to report exactly what happend and what should happen very clearly. Steven Frank (of Panic, Inc. software-makers) has made a list explaining what you should and shouldn’t do when reporting bugs. One of the things Frank specifically mentions as being good ways to convey bug reports are images and video.

A lot of open source projects use Bugzilla (of Mozilla origin) to track bugs and make discussion of those bugs possible. Shouldn’t Bugzilla make it possible (and easy!) to include images and video in bug reports?

If Buzzfeed can do it

Colourful crescendo

The artwork for Simon Jobling’s One Phat DJ August 2008 podcast: Colourful Crescendo. It’s a combination of Illustrator and Photoshop work misuse of filmgrain filters.

Originally made for the July Crescendo, a month and a few name changes later, the podcast and accompanying artwork go live today.

It’s quite fun to do podcast artwork; well recommended. Thanks for the chance Si!

 

Inserting pages into category archives in wordpress

Wouldn’t it be handy if you could have a little story at the top of your archive pages (or other templates), explaining exactly what’s what? And wouldn’t it be handy if that little story was fully wysiwyg editable? I thought so.

Sites in Wordpress (WP) have “posts” which go into categories and “pages”, which are independent. My cunning plan was to name pages exactly the same as the categories I wanted them to describe, and then insert them into the archive page. It has been quite a search to get all the right code, even though the end result looks quite simple!

The first thing you do, is create a category (”One & One”) and create a page (with the title “One & One”). Secondly, you open up your archive.php template file.

You should see something like the following in it:

<?php if (have_posts()) : ?>

And also, further along:

<?php while (have_posts()) : the_post(); ?>

Those two statements start off “The Loop”, which is wordpress lingo for the php-statements which produce the desired output (like posts or lists of them) in a template. We’re going to put our blurb above it. You can also put it under “The Loop” (the “main” loop really) if you so wish - no extra code needed.

Simply put:

<?php

$getcategory = $wp_query->get_queried_object();

$pagetoget = ‘pagename=’ . $getcategory->category_nicename;

$seperate_query = new WP_Query($pagetoget);

/* Next…we start our own Wordpress Loop, based on the seperate query (as seen above). That way we can still use the main query! */?>

<?php while ($seperate_query->have_posts()) : $seperate_query->the_post(); ?>

<div id=”blurb”>

<h3>Standard blurb for: <?php echo single_cat_title('’, false); ?></h3>

<?php the_content() ?>

</div>

<br style=”clear:both;”>

<?php endwhile; ?>

<?php rewind_posts(); /* This “rewinds” the loop, so we can use another loop after it safely.*/ ?>

Infront of the start of the main loop in your archive.php, so above of the following line:

<?php if (have_posts()) : ?>

And that’s all the code that’s needed!

Let me explain what the code actually does. The first two lines — $getcategory = $wp_query->get_queried_object(); $pagetoget = ‘pagename=’ . $getcategory->category_nicename; — ask WP for the “category slug” or the “nicename” of the category. That’s the sanitized version of “One & One” in this case, which is “one-one”.

This “category slug” is handy, because “one-one” will also be the “page slug”, so it’ll match the sanitized name of the page we want to insert into our category archive. We get our page by doing — $seperate_query = new WP_Query($pagetoget); while ($seperate_query->have_posts()) : $seperate_query->the_post(); — that starts a new, completely seperate loop from the main loop that will follow.

Then all that’s left is to insert the page’s content like so — <?php the_content() ?> — and then end and rewind the loop with the following statements — <?php endwhile; ?> <?php rewind_posts(); ?> .

You can see I’ve added a div around the content-insertion and <br style=”clear:both;”> after it. That prepares you for any floating-images that may be part of the inserted page’s content. The <h3>Standard blurb for: <?php echo single_cat_title('’, false); ?></h3> is there mainly to know what I’m doing (when working on it) and to seperate it out from the listing of category content that will follow after the blurb. I’ve left it in the example so you know how to get both the sanitized “category slug” and the regular “category title”, which this produces.

This code works in the standard Wordpress 2.6 template based on K2 and should work in pretty much all other templates too. Many thanks to Joen and Google for their help.

Bye bye liquid layouts!

Yes, I am predicting the death of liquid layout of web pages. Not all mind you, some web apps will still be liquid, but for the rest of the web: liquid is dead. This is a natural follow-through from declaring elastic layouts dead, so no surprises here.

There are three main ways to define your layout in web design: fixed, elastic & liquid. Having written about the differences between them before, I’ll suffice with stating that fixed layouts are defined in “px” (pixels) and liquid ones in “%” (percentages).

Using a fixed layout means your web page is the same width irrespective of the viewers’ screen width, like so:

Fixed layout.

Using a liquid layout however, means your web page scales along with the viewers’ screen width, like so:

Liquid layout.

Liquid layouts used to have an edge over pixel layouts in the sense that they increased use of the screen real estate, thus providing more room if the viewer increased their text-size. Line-lengths are hard to control with liquid layouts however, especially in the case of text-size increases by the viewer. Jason Kottke posted a good warning about line-lengths in liquid layouts a while back:

Attention liquid designers: take a gander at this portion of an ancient Egyptian parchment on papyrus from the Louvre. Even the ancient Egyptians knew not to make columns of text too wide.

Now, however, most browsers have adopted full-page zooming over text-size zooming. Most provide both, but full-page zooming is the new default. Full-page zooming gives users with a wider screen (for example) the chance to increase the size of text and images, while still preserving the ratios of fixed layout pages, like so:

Fixed design with full zoom.

As you can see, full-page zooming means fixed layouts also provide increased use of screen real estate, but only when needed. In addition fixed layouts keep line-lengths relatively stable, and are easy to work with as they are based on pixels, just like images, videos and other objects you may have on your web page.