Eric Mann

This is a known bug … to fix it, replace that function with:

public static function the_title( $title, $id = null ) {
    if ( null == $id ) return $title;

    $post = &get_post( $id );
    if ( 'publication' != $post->post_type )
        return $title;

    return $title . " (Download Publication)";
}

The problem is that the title filter normally passes two parameters, and some other plugins aren’t actually sending both of them. The calendar plugin you’re using is the offender in this case, but I’m not handling situations where plugins pass the wrong number of parameters. This replacement function will handle that a bit more elegantly.

Just wrap things with is_page(). You can pass in the page ID or the page slug.

So …

<div id="feature">
  <?php if ( is_page( 'drunk-driving' ) ) { ?>
    <div id="drunk-driving">
      ...
    </div>
  <?php } else { ?>
    <div id="featurearea">
      ...
    </div>
  <?php } ?>
  <div id="feature-footer">
    ...
  </div>
  <div class="clear"></div>
</div>

How is replacing: “[site_url]” a complex regex nightmare in comparison to replacing “website.com”. Seems like it’s really obvious simple string replace to me.

The way I see it, both methods are fairly expensive when it comes to processing. As it stands, post content is filtered minimally for certain shortcodes. Not a big deal, but can become one when you start installing several additional plugins.

That said, I’d much rather parse content and replace [site_url] than parse and replace website.com. It’s a more explicit flag that content needs to be replaced (think of email addresses, for example).

Using the 80/20 rule, though, the majority of users will never need this kind of flexibility. Much of these users will also be running in an uncached environment, meaning any post processing will add significant server load for every post that includes links.

That said, I can definitely see the benefit for specific groups of users and would love to see this kind of functionality extended via a plugin. Simply drop the plugin into your site and parse [site_url] like any other shortcode. Also, override the link editor to automatically insert that shortcode rather than the site URL.

I can see the value for some users, and someone (me, another dev, anyone with interest) should look into coding this out.

I was on the other side of the relative URL debate (as in, disagreeing with Otto). But there’s a very important thing to understand here – developers are not the same thing as users.

Aside from being hard-headed and simply incorrect on nearly every single front, Otto does a great job of alienating those who should constitute a significant portion of WP’s target audience: developers.

Yes, developers use WordPress to build sites. We spend a lot of time hacking code and migrating installations from one machine to another. But we are not the end user – our customers are.

Our customers couldn’t care less about relative versus absolute URLs. They just want the software to work so they can generate content, manage sales, and drive traffic to registration forms. The majority of users (remember, WP is used to power millions of sites) will not be migrating from one box/url to another and will never need relative URLs or the cacophony of things that break when they’re introduced.

Yes, relative URLs might make life easier for me. They might make things easier for you. They might make things easier for a hundred or so other developers. But focusing on a hundred or so people at the expense of millions of other users is a really bad idea.

Oh, and for the record I’ll profess right now that Otto is a WP guru. His reputation is well earned in the community.

Sharon, can you post your modified code to a Pastebin so we can see what you’ve done?