Use case

The use case was a list of gigs where I wanted to separate the upcoming gigs from the past gigs. For editor ease-of-use, I didn’t want to use the post date as the gig date, but instead chose to put the gig date in a custom field (with a little help from plugin Advanced Custom Fields).

Since it turned out to be the easiest way to accomplish what I wanted, I had the custom field save the date in the YYYY-MM-DD format. By doing that, I could reliably sort the dates “alphabetically” and not have the order break, since meta_compare treats all values as strings.

Enter meta_compare

meta_compare compares the value of a custom field to whatever other value you want to compare it with. In my case, I compared it to the date of the current day. Since I wanted two separate loops, this is what I did:

$args = array(
'post_type' => 'gigs',
'meta_key'  => 'field_gigs_date',
'orderby'   => 'meta_value',
'order'     => 'ASC',
'meta_compare' => '>=',
'meta_value' => $today,
);
$gigs = new WP_Query($args);

post_type should be self-explanatory. meta_key is the name of the custom field which holds the first value you want to compare. My field name was field_gigs_date.meta_value is the other value you want to compare, in this case a variable that holds the current date in the same format as the date in my field_gigs_date field.

meta_compare holds the operator. I wanted to display only gigs that had was happening right now or had not yet taken place, and therefore I used the greater than or equal to operator. The result is that the $gigs array contains dates that are bigger than or equal to today’s date, i.e. gigs that are happening as we speak or will happen in the future.

$args['meta_compare'] = '<';
$past_gigs = new WP_Query($args);

Since the only difference between the first and the second loop was the dates, the only thing I changed in my $args array was the meta_compare operator. The $past_gigs array will only contain gigs that have already taken place.

Final result

These two arrays were looped through in the normal WordPress fashion, by using The Loop, but modified to use the new WP_Query object instead of the default one. Instead of the normal have_posts() call, make it use the newly created query object, $gigs. The same goes for the other method calls, so the final loop should end up looking like this:

if ($gigs->have_posts()) : while ($gigs->have_posts()) : $gigs->the_post();

Exchange $gigs for $past_gigs to loop through the past gigs object. Done!

I did have a moment of doubt as whether I should stick with WordPress or switch to Drupal, but I came to the conclusion that I still agree with what I wrote earlier, and that I want to keep up with what’s going on with WordPress as well. No better way than keeping my blog running on WP.

function THEMENAME_preprocess_panels_pane(&$vars) {
// remove page titles from the page, but leave them in <title>
 if ($vars['pane']->type == "MACHINE_NAME_OF_PANE" ) {
 unset($vars['title']);
}
}

This code in the theme’s template.php, and in the panels-pane.tpl.php file, a few isset()s to check if the title is set before printing it, so as to avoid PHP notices. Come to think of it, if you set $vars['title'] to FALSE instead of unsetting it, it should probably work without changing the tpl file. Haven’t tested it, though.

The look and feel of the site will mostly stay the same, but I’m almost completely changing the structure of the site. The front page is getting a more clear “call to action” and the administrative workflow will be more intuitive. And, the site will, of course, be fully responsive. It’s the third responsive site I’m building that will actually go live, but what’s different about this one is that it’s built with a mobile first approach.

Prioritize! And wireframes.

Since I had already decided to do a restructuring with only minor changes to the graphical elements, I started where I should really always start – with wireframes. I use Mockingbird and did wireframes for four “states”: mobile, tablet, screen and huge-ass screen, starting with mobile.

Doing that really forced me to prioritize! What elements are most important? What elements do I think the visitor will find less important? If they are less important, maybe they are in fact unimportant and should be done away with altogether?

Thinking these question through left me with a very prioritized one-column layout, and extending that into two- and three-column layouts became surprisingly easy. It was “only” a matter of figuring out what options I had for reflowing content within the HTML structure that was set with the one-column layout.

Grid-less

While doing the wireframes I was using a grid for helping with proportions between elements, but once I started coding, I felt the grid classes were more of a hindrance than a help.

I haven’t quite figured out how a responsive grid is supposed to work at breakpoints where a layout changes its number of columns. Does the previously four-grid sidebar go full-width despite still having a .grid_4 class? What about a site that goes from one column on mobile to four column on large screens? It seems to me like the grid classes will have different meanings depending on the layout, and that is way confusing to me. But I’m not sure I’ve understood it all correctly.

So I took all the grid classes out.

Looking at my wireframes, I created a Panels Everywhere site template layout with five areas: header, primary content, secondary content, tertiary content, and footer. When I felt the the line-length of the one-column layout was getting too long to comfortably read, I moved the secondary content up and made it into a sidebar, and when I felt that the screen size was sufficiently large for accommodating yet another sidebar, I made the tertiary content move up into a second sidebar.

It sounds so easy…

… and it really was! Since I had done responsive before but not used the mobile first approach, I was prepared for more headaches trying to figure out where all the elements should go, and how they should get there. With all the elements prioritized and the HTML structure pretty much set from the beginning, I now feel that I have more time to fine-tune the typography and the graphical elements, and make it all look as good as possible regardless of screen size. Lessons learned:

1. Always go mobile first, because it will make you…
2. Prioritize! Between elements – most important first
3. It’s easier to scale up and add elements, than to scale down and remove elements.

It’s particularly hard to remove elements (if that’s even what you should be doing – it depends on the site) if you do not have a clear idea of what’s most important.

When you want to accomplish something, look at a piece of code that already does sort of what you want to do, copy and paste it, and modify it to work like you want it to.

Today I wrote my first Rules condition and I struggled for a quite some time with accessing the parameter I wanted from my condition function. I wanted a node object, and despite digging through the documentation I couldn’t seem to get it right. (Or, as it turned out, I actually got it right but must’ve mistyped something, but that’s beside the point.) Giving up, I turned to Mattias and as soon as he’d understood my plight he told me to look at an exisiting condition that did just that – accessed a node object.

For example, the very standard “Content is of type” condition.

Problem solved in less than two minutes. I am writing it down in the hopes of actually remembering this all by myself next time.

Nu ska jag “bara” se till att detta blir starten på regelbunden träning! Två gånger i veckan fram till jul, det borde väl inte vara omöjligt?

We’re calling it Filefield Zip, and it takes files from one or more selected file fields and zips them into one single zip-file. Right now, that’s all it does, but we’re planning to add Views support for a link to download the zip file and a whole bunch of other features. This module started as a project for a NodeOne client whose site is on Drupal 6, so for now the module is for D6 with plans to port it to Drupal 7 when we have time.