How to split your WordPress posts into two columns

The other day, whilst merrily making a website for an ensemble called Tesserae, I needed to figure out how to display my posts in 2 columns, side by side. In this case, the posts were a custom post type biographies that I used to display the various members biographies on the site.

It wasn’t hard to do, here’s the code I used to display half of the posts:

<?php // Get the number of posts in the custom post type 'biographies'
$count = wp_count_posts( 'biographies' ); ?>

Let’s say the total number of posts is 7.

<?php // Divide the number of published posts by 2 and round up in case we get a fraction
$num_biogs = ceil( $count->publish / 2 ); ?>

This would give us 4. We must round up this number otherwise, we’d get 3.5 and that’s no good!

<?php // Now use this number for the showposts parameter in our query
$biogs = new WP_Query( 'post_type=biographies&showposts=' . $num_biogs );
while ( $biogs->have_posts() ) : $biogs->the_post();
// the_title(); the_content(); etc
endwhile; wp_reset_query(); ?>

And the remaining posts:

<?php // Now use the variable $num_biogs as the offset parameter in another query
$biogs = new WP_Query( 'post_type=biographies&showposts=-1&offset=' . $num_biogs );
while ( $biogs->have_posts() ) : $biogs->the_post();
// the_title(); the_content(); etc
endwhile; wp_reset_query(); ?>

Obviously this is only the PHP, and you’re going to need some HTML there to actually use this! I just floated a couple of <div>s side by side, then popped the first block of code inside the left-hand <div> and the 2nd chunk in the 2nd <div>.

You can see the finished product at http://tesserae-la.com/who/

jQuery mobile events firing multiple times and what to do about it

I’m currently working on my very first iPhone app. I decided I’d build it in HTML5, CSS3, JavaScript and wrap it up all cosy and warm with the amazing PhoneGap. I also decided early on to use jQuery mobile as my framework for the project, because I’m so familiar with jQuery itself. It’s been quite a ride so far and I’ve learnt a LOT!

I soon found out that dynamic content and jQuery mobile is not the easiest of pairings, but I think I’ve found a good solution to the most common problems I encountered and figured it’d be cool to share them with whomsoever might have a use for them.

One of the issues I found with my code early on was that on subsequent visits to a page, events would be fired an increasing number of times. What was happening was that I was binding events to the pagebeforeshow event – I though I had to this, because most of the content I was adding to the page was dynamic and would be updated on subsequent page visits. I did this:

$('#my-page').bind('pagebeforeshow', function(){
  // Add dynamic stuff to the page here, then...
  $('input').bind('change', function(){
    // Do something when this happens
  });
});

This worked for the dynamic content, although I still had to remove my inserted content on pagehide as jQuery mobile saves the page in memory, which drove me to the brink of madness on more than one occasion, but hey. On change, the input event was duly triggered on my first visit to the page (and only once, as I expected), but on my second visit to the page, the event was triggered twice, then 3 times etc. Eek!

The solution was not difficult, it just took a while to figure out. I still added my dynamic stuff to the page using the pagebeforeshow event, but I just added the event listener for my input to pageinit instead. As most of the event listeners were bound to elements that were inserted dynamically, I had to use live instead of bind. In the end my code looks something like this:

$('#my-page').bind('pagebeforeshow', function(){
  // Add dynamic stuff to the page here
}).bind('pageinit', function(){
  $('input').live('change', function(){
    // Do something when this happens
  });
});

That solved it. I might detail how I add and remove dynamic content to the page using pagebeforeshow and pagehide. If it might be of use to anyone, do let me know if so!

A suggested fix for the dreaded FOUT

As a keen typography fan I tend to rely heavily on the use of web fonts for my sites. I generally use Typekit to deliver my fonts, but it does tend to take a little while for the browser to download and display my beautiful fonts.

I noticed that if I simply place the typkit required script tags in the header of my site, it will block my site from loading until the font(s) have been downloaded, leaving visitors with a blank screen for a second or so. With a fast connection it’s not the end of the world in my book, but recently I tried experimenting a little with how to minimize this inconvenience to the user.

First, I tried putting the typekit script tags in the footer of my document, instead of the header. This stopped the delay in the site from loading, but it also caused a ‘Flash of Un-styled Text’ (or FOUT for short), where the fallback font(s) were shown as the web fonts were being downloaded. This can look really messy, especially if you’re using fonts for which there isn’t really any suitable fallback.

It’s a common problem and I’ve seen a couple of solutions offered, but I came up with what I think is quite an elegant solution.

Typekit fonts are delivered via JavaScript that provide event listeners that can tell you whether a font is active, is loading, is inactive or has been loaded. Typekit suggest a solution on their blog at http://blog.typekit.com/2010/10/29/font-events-controlling-the-fout/, but the loading of your site can still be delayed as you wait for the fonts to download and if you put the script tags in your footer, you can still suffer the FOUT. Blurgh.

My solution is to (and bear with me here before you scream ‘but what if JavaScript is disabled!’) hide all the text elements in my CSS by setting their opacity to 0, so as to completely avoid any FOUT. I do this like so:

h1, h2, h3, h4, h5, h6, p, ul, ol, dl, span, a {
opacity: 0;
-webkit-transition: opacity 0.4s ease-in;
-moz-transition: opacity 0.4s ease-in;
-o-transition: opacity 0.4s ease-in;
transition: opacity 0.4s ease-in;
}

Obviously you may well have more elements of text that should be hidden, such as blockquotes, cites etc. I’ve also added some CSS3 transitions, so that when the web fonts have finished loading they’ll fade in smoothly (this in itself is really quite a nice effect) rather than just being spat out! I then added the following to my CSS:

.wf-active h1, .wf-active h2, .wf-active h3, .wf-active h4, .wf-active h5, .wf-active h6, .wf-active p, .wf-active ul, .wf-active ol, .wf-active dl, .wf-active span, .wf-active a {
opacity: 1;
}

The .wf-active class is added to the <html> tag of my document via JavaScript when the font has finished loading. If we set the opacity here to 1 then our web fonts will be displayed and not our fallback fonts.

The problem with this method is obviously that it relies on JavaScript. If users view the site with JavaScript disabled, the wf-active class won’t be added to the <html> tag and the fonts will remain invisible. My solutions is to add the following to my document head after our other CSS files have been included.

<noscript><style>h1, h2, h3, h4, h5, h6, p, ul, ol, dl, span, a {
opacity: 1;
} </style></noscript>

This will overwrite our previous declaration where we set the opacity to 0 and therefore make our fallback fonts visible to the user without JavaScript.

The other problem with this method if the Typekit fonts are not available, or if the browser does not support web fonts. In this case, you could also use the .wf-inactive class which Typekit adds to the <html> tag in either of these cases and set the opacity to 1 like so:

.wf-inactive h1, .wf-inactive h2, .wf-inactive h3, .wf-inactive h4, .wf-inactive h5, .wf-inactive h6, .wf-inactive p, .wf-inactive ul, .wf-inactive ol, .wf-inactive dl, .wf-inactive span, .wf-inactive a {
opacity: 1;
}

As far as I can see this pretty much covers all bases, but I may well have missed something here and am very happy to have this pointed out to me!

Easy PayPal Custom Fields Plugin

I’ve just my first WordPress plugin that uses custom fields to make creating a PayPal button super-easy.

I wanted to learn more about PHP and the inner workings of WordPress and I also needed a solution for my clients to add PayPal functionality to their sites without having to remember complicated shortcode syntax. Whilst shortcodes in WP are a fantastic feature and are easy to implement for the developer, I find they can often confuse my clients who often can’t even find square brackets on their keyboards!

Having said that: In order to have full flexibility on the placement of this mystical button, you can select to insert it at the top or bottom of a post or – via a shortcode – anywhere you like in the post.

On the settings screen, the user can select on which type of post (including custom post types) the plugin should be displayed. It’s also possible to enter default settings which can subsequently be changed for individual posts where necessary – this might come in for sites with multiple users.

The button is also customizable with 2 themes to choose between (dark and light) with custom text for the button, or it’s possible to simply display a regular large or small PayPal button (either ‘Buy Now’ or ‘Donate’).

The plugin will encrypt your PayPal username so that it can’t be harvested for spam by the evil spam robots of Mordor.

This plugin is created for WordPress 3.x and currently only supports ‘Buy Now’ and ‘Dontate’ functionality. Download it via the WordPress plugin repository.

Please don’t forget to rate the plugin if you like it and if you feel generous enough to lend a few shillings towards further development I would be most grateful.

Update: I’ve managed to fix an issue where WordPress would suddenly remove the PayPal info attached to the post and the button would disappear. I’ve updated the repository with the fixed version – if you’re using an older version I strongly recommend that you update as soon as possible!

Screenshots:

The Options Page


Adding the button to a new post:


Obbligato bass instruments in 17th century Italian instrumental chamber music

Today, it’s practically a given that the continuo part in 17th century Italian instrumental chamber music will be doubled by a bowed bass (or other bass) instrument. Is there any evidence to support this practise?

In 17th century Italian music, the continuo instrument is often unspecified, but where it is specified (for example in the books of Castello) it is the organ, and where another instrument is suggested it is the harpsichord, or spinetta.

Whilst I don’t think it sounds bad to have multiple continuo instruments accompanying a sonata, I have never found any evidence to support this approach. It’s clear from surviving music that the most common continuo instrument for 17th century Italian chamber music was the organ. There is no evidence to suggest that the continuo (keyboard) part was doubled by any other instrument – this includes the theorbo!

Evidence!

I think it’s fundamentally wrong to, lacking any evidence, simply assume that the continuo part was doubled by any other instrument. Nonetheless, this has become an accepted part of modern practice. And it pisses me off. We shouldn’t just accept earlier assumptions about historical performance and that what we hear on recordings to be historically correct!

I feel that doubling the continuo part gives it undue importance for this repertoire. The continuo parts rarely if ever contain thematic material, rather serve to support the solo parts. As a continuo player myself, I know this is no ‘minor’ role, but nor should it have too much attention drawn to itself.

Ok, enough already. If it is the case that the continuo part was not doubled, when is it appropriate to use a bowed bass instrument? The answer I believe is simply: When there is an obbligato bass part.

Obbligato Bass Parts

There are TONS of sonatas with obbligato bass parts from the 17th century. Frescobaldi (amongst others) even writes sonatas with more than one obbligato bass part. Fontana is good example – he lists the cornetto and violin as possible soprano instruments and the bassoon, theorbo and ‘violino’ as potential bass instruments for his sonatas. These bass instruments should only play when there exists a part for them, they are not mentioned or intended to be ‘continuo’ instruments. In fact, no mention of any continuo instrument is made, and we can assume this to be the organ, or harpsichord.

The Role of the Theorbo

This is another article in itself, but I’d like to mention here that the theorbo isn’t suggested as a continuo instrument for instrumental music in Italy at all in the first half of the 17th century. (There are 2 exceptions, which in fact aren’t really exceptions… Rossi and Marini, where the theorbo is listed as the only bass instrument [ie. without organ]. Here however the theorbo part is both a continuo and obbligato part, equal to the other solo parts). However, the theorbo is mentioned as an obbligato bass instrument by many composers of the period including Frescobali, Uccellini, Marini, Turini, Corelli, Sanmartini, Pittoni, Cazatti, Cavalli, Guierierro etc. etc. It seems clear to me that the theorbo, whilst an unlikely continuo instrument for this repertoire, was frequently employed as an obbligato bass instrument.

For what it’s worth

My advice: Don’t use a bowed bass (or any other bass instrument, including the theorbo) unless there is an obbligato bass part. If you have a group with theorbo, organ and violone, find a sonata with 2 obbligato bass parts, or take it in turns to play sonatas with obbligato bass parts.

I must stress that my ramblings refer only to 17th century Italian instrumental chamber music. We shouldn’t apply the same rules to secular vocal music for instance, where the theorbo was a hugely popular continuo instrument and the organ was seldom used.

Violone: 8 foot or 16 foot?

Finally – ‘violone’ is a really confusing term that meant different things at different times in different places. However, we can be pretty darn sure that for 17th century chamber music – including and especially for music by Biber and Schmeltzer – that ‘violine’ implies a bass instrument that plays at 8 foot pitch. Bibers’ battallia for instance has 2 ‘violine’ parts, each clearly intended for an instrument that plays at 8 foot pitch. I have no doubt that 16 foot instruments existed at this time, but their role in chamber music is doubtful at best.

In short, if historical accuracy is your bag, I recommend not doubling the keyboard part, if not – happy doubling!