Friday, 10 June 2016

Resorting Taxonomy Listing by Meta_Value

To sort a taxonomy in the front end by a meta_value put this in your theme:

$terms = apply_filters( 'get-terms', array('taxonomy'=> 'TAXONOMY_TO_REORDER', 'meta_key' => 'YOUR META_VALUE KEY','orderby' => 'meta_value', 'order' => 'DESC'));

To sort a taxonomy in the admin view by a meta_value put this in your functions.php:

add_action('get_terms_args', 'custom_get_terms_args', 1, 2);
function custom_get_terms_args($args, $taxonomies) {
if (in_array('TAXONOMY_TO_REORDER', $taxonomies)) {
$args['orderby'] = 'meta_value';
$args['meta_key'] = 'YOUR META_VALUE KEY';
$args['order'] = 'DESC';
return $args;

Tuesday, 5 March 2013

Client Launches: Now Responsive

From the official press release on my recent work with the team

“‘Our goal is to provide readers with a positive, consistent experience and easy access no matter where they are and regardless of their chosen device, be it a desktop computer, laptop, e-reader, tablet or smartphone’, says Jamie Martin, Experience Life’s digital initiatives manager. ‘Mobile traffic to our site has increased significantly over the past two years, with more than a third of our traffic coming from smartphones and tablets. Our new responsively designed site allows for the flexibility readers want and deserve.'”

Also includes this quote from me:

“One of the most cost-effective ways for web publishers to make sure their sites offer real functionality no matter their users’ choice of platform or screen size is through responsive design.”

Wednesday, 10 October 2012

How To Create Default Posts or Pages in a WordPress Network Site

Add this to your default theme’s functions.php

function grv_create_default_pages() {
// Create New Default Page
$args = array(
'name' => 'new-default-page',
'post_type' => 'page',
'post_status' => 'publish',
'showposts' => 1,
'caller_get_posts'=> 1
$default_page = array(
'name' => 'new default page',
'post_title' => 'NEW DEFAULT POST TITLE',
'post_content' => 'lorem ipsum dolor',
'post_status' => 'publish',
'post_author' => 1,
'post_type' => 'page'
// Insert the New Page into the database
$new_page_exists = get_posts($args);
if ( empty($new_page_exists) ) {
$new_page = wp_insert_post( $new_page );
// Uncomment if you've a custom template that should be applied to the default page
// update_post_meta($new_page, '_wp_page_template', 'custom-tempate-page.php');
// Wanna add some default links? Here you go.
$linkdata = array(
'link_name' => 'Garrick van Buren',
'link_url' => ''
$link_id = wp_insert_link( $linkdata );
add_action( 'after_setup_theme', 'grv_create_default_pages' );

Saturday, 24 December 2011

Client Launches: &

I’m happy to announce two new client sites launched this week: one for Experience Life magazine and one for Minneapolis advertising and design studio .

Both sites are powered by a heavily-customized WordPress installation.

The Experience Life effort included the development of a system to migrate 10 years of archives, comments, assets, URLs (including shortened URLs) into WordPress. Additionally, WordPress was customized to be organized around monthly issues rather than blog post chronology.

The focus of the Fellow effort was in successfully merging the unique creative vibe of Fellow and the reliability of WordPress.


Thursday, 4 August 2011

How to Share Sidebars Across a WordPress Network

On a recent WordPress Network (WPMU) project, I’ve needed to display the same sidebar and associated widgets across all the sites in the entire network.

Since switch_to_blog() has been deprecated and an attempt at monkey-patching sent me deeper into the bowels of WordPress than I felt was warranted…

I turned all the necessary widgets into pages and used get_blog_post($blog_id, $post_id) to build the widgets by hand.

<?php $posts = array(5304, 5322, 5309, 5310, 5301, 5299); foreach ($posts as $post_id) : ?>
<?php $post = get_blog_post(1, $post_id ); setup_postdata($post); ?>
<div class="widget">
<h4><?php the_title(); ?></h4>
<div class="textwidget">
<?php the_content(); ?>
</div><!-- widget -->
<?php endforeach; ?>

The downside – widgets need to be manually added, moved, and removed from the array.

The upside – it works.

Wednesday, 4 May 2011

WordPress + Thickbox Requires Markup

I’ve been fighting with getting the contents of a WordPress page to display within Thickbox.

The great thing about WordPress, is that wiring this up is super straight forward.

  1. Tell WordPress you want to use thickbox in your theme by adding it to the functions.php file
    function init_theme_method() {
    add_action('init', 'init_theme_method');
  2. Update the paths to the thickbox images (cause WordPress can still get confused about something sometimes)
    <script type="text/javascript">
    if ( typeof tb_pathToImage != 'string' )
    var tb_pathToImage = "< ?php echo get_bloginfo('url').'/wp-includes/js/thickbox'; ?>/loadingAnimation.gif";
    if ( typeof tb_closeImage != 'string' )
    var tb_closeImage = "< ?php echo get_bloginfo('url').'/wp-includes/js/thickbox'; ?>/tb-close.png";

The I spun up a get_post_content function:
function get_post_content($post_id) {
global $wpdb;
$data = $wpdb->get_results("SELECT * FROM $wpdb->posts WHERE ID=$post_id");
return $data[0]->post_content;

and added it as a hidden div in my footer.php
<div id="about" style="display:none;">
<?php echo get_post_content($id); } ?>

and created a link to launch the thickbox <a href="#TB_Inline?inlineId=about" class="thickbox"</a>

But it was blank.


Nothing in the box.

Turns out thickbox requires some markup – any markup – within the requested inlineId.

<div id="about" style="display:none;">
<p><?php echo get_post_content($id); } ?></p>

Friday, 23 July 2010

Thesis’s Next Opportunity: Un-WordPress Itself

A long running controversy in the WordPress community was resolved this week when the popular, commercial theme Thesis was re-licensed making it compatible with WordPress’s own GPL license. This re-licensing confirms WordPress themes and plugins must be released under the GPL. This is great news for the WordPress community for it reinforces the type of culture and ecosystem around the WordPress codebase it’s maintainers intended.

From my perspective, Thesis had 2 resolutions available – adopting the GPL was the quickest way to resolve the issue, and I suspect the impact on commercial side won’t be as significant as feared. Unfortunately, this decision means Thesis will always be just a WordPress theme.

The second resolution, available to all WordPress developers, is to divest themselves of all WordPress code. Every line, every call, every function – remove it form the Thesis code base. Then hire a team of PHP developers unfamiliar with the WordPress codebase to custom develop the application from the ground up – interacting with pre-existing WordPress database structure.

A complete clean-room developed, drop-in replacement for WordPress.

Licensed and distributed however the project sponsor wants.

This solves a number of increasingly irritating technical issues I have with WordPress;

  • WordPress is increasingly an attack target resolved with seemingly endless codebase updates,
  • the WordPress admin UI continually less about writing,
  • the WordPress theme templating structure encourages redundant code.
  • Most importantly – the self-hosted, reliable, usable, website engine space needs some innovation.

This approach confirms Thesis is, much more than a WordPress theme (one of the controversial points), but a mature, stand-alone WordPress replacement [1].

This approach is far more interesting to me and I think has the opportunity to foster greater energy, excitement, and innovation in a very stagnant feeling space.

P.S. I say all this someone who; has written a bunch of code to interact with WordPress, currently maintains a number of WordPress blogs, continually recommends WordPress the starting point for all publishing-heavy web projects.


“Because my relationship with WordPress has been souring for longer than the recent problems, I’ve been working on a replacement for WordPress…” – J Wynia

1. Yes, this was the idea behind my PressOnRails project – an effort to use Ruby on Rail to interact with a pre-existing WordPress database.

Tuesday, 20 July 2010

Adding Custom Fields to an Existing Post via XMLRPC in WordPress

If you’re having difficulty adding custom fields to an existing WordPress posts via XMLRPC’s metaWeblog.EditPost command, try including a dummy entry in your code.

It worked for me.

I’m working on a project where we’re programmatically adding WordPress custom field data to thousands of posts, seemed like a great job for XMLRPC. I had assumed a simple Ruby call like this would work:

result ='metaWeblog.editPost', wordpress_post_id, name, pass, {"custom_fields" => [{"key" => "note", "value" => "loves you"]})

It doesn’t – it gives a less than happy Error 500 ‘Sorry, your entry could not be edited. Something wrong happened.’

I read through WordPress’s xmlrpc.php file and noticed that the update post command is run (line 2460) before any of the custom field data is recognized (line 2476).

So, I added a line to not change the Post’s title, and new custom fields were added as expected.

result ='metaWeblog.editPost', wordpress_post_id, name, pass, {"title" => POST_TITLE, "custom_fields" => [{"key" => "note", "value" => "loves you"]})

Thursday, 25 June 2009

What’s Wrong with WordPress?

You know I’m a big fan of WordPress. For nearly 5 years, I’ve considered it the only online publishing platform worth considering.

I’ve built a number of plug-ins for it over the years(WP-iPodcatter, WP-iCal, WP-GotLucky, and WP-CaTT) of which I only use WP-iCal these days.

Since then, WordPress has taken off.

While they still have the 5-minute install, I feel much of the simplicity of the project has been lost.

While huge efforts have been made to make the admin side more usable and approachable, I’ve been having more and more technical issues with each successive upgrade.

Here’s a handful that come to mind immediately:

  • Auto-upgrading to WordPress 2.8 wiped out all 10 of my domains on that server (including my kids photoblog – the Grandparents are not pleased).
  • Even before then, auto-calculating the enclosure data on the podcast has been hit and miss for me (more miss when post is initially saved as a draft).
  • I’m not clear on the difference between Categories and Tags, and I prefer Categories. seems to prefer Tags.
  • No non-RSS/Atom outbound feeds (e.g. iCal, KML, JSON, etc) without use of plugins.
  • XML-RPC payload data is unreliable for me (again, Grandparents are not pleased).
  • Theme injection spam attacks regularly hiding links in my sites.
  • An increasing percentage of the WordPress community that seems just this side of spammers.
  • My WordPress URL Shortening Hack suddenly stopped working.

Now, I’ve no interest in migrating 5+ years of data – across countless installs – out of WordPress. Nor do I see another online publishing project as focused on simplicity, flexibility, and extensibility.

I also have no interest taking my chances on another destructive upgrade.

So, I’m experimenting with some ideas, and so far, I’m feeling optimistic.

Monday, 6 April 2009

WordPress URL Shortening Hack

My last post, Publishers Shorten Yourself, got me thinking about easy, low-tech ways to provide a short url for WordPress blogs.

Turns out, just 1 line of code is needed in the .htaccess file.
RewriteRule ^(d+)$ http://[YOUR-BLOG-URL]/?p=$1

Add it in just after RewriteBase so your .htaccess looks something like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^(d+)$ http://[YOUR-BLOG-URL]/?p=$1
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

To use this short URL in your templates do one of the following:

If you want to use the same domain your blog is on, use this:

<a href="<?php echo get_option('home'); ?>/<?php the_ID(); ?>"><?php echo get_option('home'); ?>/<?php the_ID(); ?></a>

If you have a different, perhaps shorter domain, use this:

<a href="[SHORT-DOMAIN]/<?php the_ID(); ?>">[SHORT-DOMAIN]/<?php the_ID(); ?></a>

Note: You will have to add an additional redirect to the .htaccess file of SHORT-DOMAIN, but that’s not problem, because it’s very similar to the WordPress redirect we started with.

And like that you’ve got a short url, for every post in your WordPress blog. No more worries about whether or not a specific URL shortener will be stealing your referrers or even be around tomorrow.