remove_filter('the_content', 'wpautop');
remove_filter('the_excerpt', 'wpautop');

I’m not the only one to do this. But, I’m tired of having to manually type <p>s for every paragraph in every post that I write.

I’d like to be able have it back on, but preferably a bit smarter so that you don’t get all that crap (also common on bulletin boards with empty paragraphs around undetected block-level elements, especially if these are non-standard, related to plugins.

At the very least I want to be able to turn it off for when it does annoy me, on these moments that I don’t want auto-anything. Also, I need this if I don’t want to break the nearly 300 posts that I formatted manually. So, I want to use a custom field to turn the filter on or off.

I found an unpublished plugin (unpublished in the sense that the source isn’t hosted somewhere proper such as wordpress.org/extend/plugins/) which does some of what I want in a somewhat messy unmaintained manner. After years of just entering those damn <p>s (and over a year since this draft was in the making), I decided to do my own plugin for post-by-post (and global) control of the wpautop filter. It’s called wpautop-control:

<?php
/*
Plugin Name: wpautop-control
Plugin URI: http://blog.bigsmoke.us/tag/wpautop-control/
Description: This plugin allows you fine control of when and when not to enable the wpautop filter on posts.
Author: Rowan Rodrik van der Molen
Author URI: http://blog.bigsmoke.us/
Version: 1.0
*/
 
if ( is_admin() ) {
  add_action('admin_menu', 'wpautop_control_menu');
  add_action('admin_init', 'wpautop_control_settings');
 
  function wpautop_control_menu() {
    add_submenu_page('options-general.php', 'wpautop-control', 'wpautop control', 'manage_options', 'wpautop-control-menu', 'wpautop_control_options');
  }
 
  function wpautop_control_options() {
    if (!current_user_can('manage_options'))  {
      wp_die( __('You do not have sufficient permissions to access this page.') );
    }
 
  ?>
  <div class="wrap">
    <h2>wpautop control options</h2>
 
    <form method="post" action="options.php">
      <?php settings_fields('wpautop-control') ?>
      <table class="form-table">
        <tr valign="top">
          <th scope="row">wpautop filter on by default?</th>
          <td>
            <label><input type="radio" name="wpautop_on_by_default" value="1" <?php if ( get_option('wpautop_on_by_default') == '1' ) echo 'checked="1"' ?>> yes</label>
            <label><input type="radio" name="wpautop_on_by_default" value="0" <?php if ( get_option('wpautop_on_by_default') == '0' ) echo 'checked="1"' ?>> no</label>
          </td>
      </table>
 
      <p class="submit">
      <input type="submit" class="button-primary" value="Save Changes" />
      </p>
    </form>
  </div>
  <?php
  }
 
  function wpautop_control_settings() {
    register_setting('wpautop-control', 'wpautop_on_by_default', 'intval');
  }
}
else { // ! is_admin()
  add_filter('the_content', 'wpautop_control_filter', 9);
 
  function wpautop_control_filter($content) {
    global $post;
 
    // Get the keys and values of the custom fields:
    $post_wpautop_value = get_post_meta($post->ID, 'wpautop', true);
 
    $default_wpautop_value = get_option('wpautop_on_by_default');
 
    $remove_filter = false;
    if ( empty($post_wpautop_value) )
      $remove_filter = ! $default_wpautop_value;
    elseif ($post_wpautop_value == 'true')
      $remove_filter = false;
    elseif ($post_wpautop_value == 'false')
      $remove_filter = true;
 
    if ( $remove_filter ) {
      remove_filter('the_content', 'wpautop');
      remove_filter('the_excerpt', 'wpautop');
    }
 
    return $content;
  }
}
 
?>

(I’ve requested the plugin to be added to the WordPress plugin repository, so that it won’t have to be reinvented another 20 times in the next year or so.)

After installing the plugin, you can choose whether to enable or disable wpautop by default. Then, for every post where you want to deviate from the default, you can set the wpautop custom field to ‘true’ or ‘false’.

I want the new default to be to enable the filter, but since all my old posts have been manually formatted, I want all these to have the wpautop field added and set to ‘false’.

Adding the appropriate custom field values to all existing posts is easy thanks to MySQL’s INSERT … SELECT syntax:

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
     SELECT wp_posts.ID, 'wpautop', 'false'
       FROM wp_posts
      WHERE post_type = 'post';

This is how the pagination for page one of my home looks now:

For page six you can see more of what the plugin can do:

And finally…

Do I have twenty pages of posts already?

At some time, I had already installed (but not activated) the Live Comment Preview plugin, but that’s client-side only. I removed it because I want the comment to show as it would after being piped through all the hooks and filters that comments normally get piped through. Enter the AJAX Comment Preview plugin:

Other preview plugins don’t know what sort of changes WordPress will make to a visitor’s comment, but this plugin uses AJAX and other buzzwords to send each previewed comment through WordPress’ inner voodoo.

The result? With the click of a button, your site’s visitors can preview their comments exactly as they will appear when they submit them for realies.

You just gotta love their phrasing. Enjoy the new preview feature.

Dan Peverill’s GeSHI plugin sucks for two reasons:

1. It’s no longer being maintained. It doesn’t even seem to justify a page on Dan’s website anymore (for which reason I’m not going to give him any link-juice).
2. It breaks HTML. With the plugin enabled I can no longer use the <code> tag to mark in-line elements as being code. Frankly, this is annoying and I find myself typing <tt> often when I mean <code>.

A search for WordPress plugins tagged GeSHi reveals a number of results: Sniplets, CodeColorer, Developer Formatter, and WP-SynHighlight. WP-Syntax is a plugin that is missing from the tag search.

Sniplets seems much too generic to my taste. I just want a GeSHi highlighter, period.

CodeColorer says it does what I want, but if I ever want to use the TinyMCE editor again, I won’t be able to with this plugin. Shouldn’t be too much of a problem, but still…

Developer Formatter is very thoroughly written and even sports a TinyMCE plug-in for copying/pasting the code. It is pretty big, though, and, as a rule, I tend to avoid plug-ins that complicate the database schema. I also don’t really see how these extra tables are an advantage feature-wise.

WP-SynHighlight uses a custom BBCode-style tag, [codesyntax] I like this (if you’re going to use pointy brackets, at least keep out of the HTML namespace), though I don’t like the attempt at a generic name; what’s wrong with calling the tag [geshi]? Seriously… I’m sure I’m going to forget this name billions of times if I’ll use this plug-in.

WP-Syntax uses the <pre> tag with a few custom attributes. This at least is better than the officially inline <code> tag that my current plugin uses, because most of the time that I’d use a <pre> tag I really do want syntax highlighting. Just wondering: will it also allow my to use it normally for that other rare occasion? Sadly, the plugin will doubtlessly wreak havoc with the visual (TinyMCE) editor.

So, which plugin will I choose? I am somehow inclined to want a plugin that can play nice with the visual editor because I keep telling myself how much nicer it would be to switch to the visual editor for all my posting. (That this will be difficult because I disabled WP’s ‘wpautop‘ filter to rid myself of its eagerness is a story for some later time.) This requirement rules out CodeColorer and WP-Syntax.

That leaves Developer Formatter and WP-SynHighlight. Both seem to fit my purpose. Developer Formatter sports a nice TinyMCE plugin for inserting code, but I don’t think that switching to TinyMCE will suddenly and unexpectedly make me afraid of typing. Besides, I really don’t want the extra tables in my database without a very good reason, so, for now, I will try WP-SynHighlight.

Vertical navigation

Ever since the first time that I saw a blog which featured vertical navigation instead of the typical columns, I’ve wanted to implement this for myself. Well, finally…

Site-wide elements use the complete width of the page. The page content is centered in the middle at 87.5%. The identity stuff in the header and the navigation in the footer sits against a back blackground while the content area has the proven black on white for easy reading. I hope that the strong color-contrast as well as the clear difference in with between site-wide elements and page content makes it easy to keep focused on either reading or navigating without distractions.

… and a talkative footer

With this theme, I didn’t want another footer which consist of the odd logo and some loose copyright statements. I wanted a footer which you can actually read, even understand. And who cares if it takes up a little space? It’s at the bottom of the page.

Related posts

I’ve written an (unpublished, unpolished) plug-in which can generate a list of posts that are chronologically related. Traditionally, most blogs have a next/previous post link at the top and bottom of each post. This works very well if you limit your blog to one subject (which is really a very good idea anyway), but if, like mine, your blog is a little bit messy, you could say that someone who stumbled here searching for an article about Subversion is not necessarily interested in the next post if this is a photo of my baby niece.

Hence the chronologically related posts plugin. With this plugin I can say wether I want a link to the first, previous and next post in the blog, within the same category, or matching a given number of tags. (The tag matching isn’t implemented yet, though. Also, matching on meta fields would be a kick-ass ass way to support explicit sequences.)

I put the list generated by this plug-in on top of a blue background besides the various context links of the post.

Issues left

I hope to have the first major revision of my theme ready soon. Here’s a list of some issues that I might address:

• The CSS renders a bit psychedelically in MSIE 6 (only version I tested) at the moment. Sigh… Let’s just hope that IE 7 will give better results. Then I’ll gladly drop the IE 6 support.
• When viewing a category, the tag cloud in the navigation panel at the bottom only shows tags for that category. This has to do with the use with me calling the st_tag_cloud() from within the category template.
• Some of the elements that I just showed to you don’t really look that good and most elements that I didn’t can be said to be … hideously ugly. Some highlights: the header (should really be a few cool images), the comment form, and the Next/Previous Page links.

Comment!

I’d almost forget all about the clean, new look of the comment list. And, if you register a Gravatar, your comments will be accompanied by your avatar. Try it. Please!

The plugin works great and allowed me to post http:///2007/05/30/jeroen-dekker.com with dots and without problems.