Ask Mark Anything

People ask me a lot of questions. About WordPress and web development for sure, but also about other topics. I’ve decided to try a little experiment: a public way to ask me questions. Zach Holman from GitHub had the idea to use a GitHub issue tracker for this very purpose, and I think it looks like a splendid idea.

Benefits:

  • Allows for more in-depth discussions than Twitter (but you can still talk to me on Twitter for quick questions).
  • Is public (as opposed to e-mail).
  • Forces me to deal with questions.

Now, note that this doesn’t mean I want you to treat me like your personal Google-searcher or WordPress code grepper! But if you think there is a WordPress (or other) topic that I am uniquely qualified to address, just ask.

Don’t use template_redirect to load an alternative template file

template_redirect is a popular WordPress hook, for good reason. When it runs, WordPress has made its main query. All objects have been instantiated, but no output has been sent to the browser. It is your last stop to hook in and redirect the user somewhere else, and the best place to do so if you need full knowledge of the queried objects. But what it is not good for is loading an alternative template.

I see code like this a lot:

add_action( 'template_redirect', 'my_callback' );

function my_callback() {
  if ( some_condition() ) {
    include( SOME_PATH . '/some-custom-file.php' );
    exit();
  }
}

The problem with this code is that anything hooked in to template_redirect after this code isn’t going to run! This can break sites and lead to very odd bugs. If you want to load an alternative template, there’s a filter hook for that: template_include.

add_filter( 'template_include', 'my_callback' );

function my_callback( $original_template ) {
  if ( some_condition() ) {
    return SOME_PATH . '/some-custom-file.php';
  } else {
    return $original_template;
  }
}

Same effect, but doesn’t interfere with other plugin or theme code! This distinction should be easy to remember:

  • template_redirect is for redirects.
  • template_include is for includes.

Six Apart Suspends Movable Type Open Source Project

Six Apart announced that they are suspending the free and open source version of Movable Type. Here’s what I had to say about them revealing the free and open source version of Movable Type, back in 2007.

Note that this also allows Six Apart at any time in the future to say “As of today, we are no longer releasing a GPL version of Movable Type.” And that would require that someone fork the code in order to proceed with development. WordPress can’t easily do that, as it is not owned by a single legal entity.

What a GPL’d Movable Type means for WordPress

When I wrote that, I honestly didn’t think it was going to happen. I was just saying that it was an option that was open to them. But here they’ve gone and done it. What a bizarre saga this has turned out to be. “Life is funny”, remarks Anil Dash, former Six Apart Chief Evangelist.

Will this start a conversation about copyright assignment on open source projects, or is this a non-event? If a project has a strong open source development community, an attempt to close it down should result in a fork of the project. As it happens, Movable Type Open Source was already forked. Several prominent Movable Type people created Open Melody back in 2009. Don’t bother clicking that link. As of this writing the site is non-operational. The Open Melody Twitter account just recorded its first activity in over two years. A retweet of this:

I guess we’ll find out!

Fragment Caching in WordPress

Fragment caching is useful for caching HTML snippets that are expensive to generate and exist in multiple places on your site. It’s like full page HTML caching, but more granular, and it speeds up dynamic views.

I’ve been using this fragment caching class for a few years now. I optimized it around ease of implementation. I wanted, as much as possible, to be able to identify a slow HTML-outputting block of code, and just wrap this code around it without having to refactor anything about the code inside.

Implementation is pretty easy, and you can reference the comment at the start of the code for that. The only thing to consider is that any variables that alter the output need to be build into the key. It should also be noted that this code assumes you have a persistent object cache backend.

WordPress 3.6: shortcode_atts_{$shortcode} filter

Since WordPress 3.6 is in beta, I thought I’d use this nearly-abandoned blog (hey, been busy working on WordPress!) to talk about some of the cool stuff for developers. For the first installment, check out the new shortcode_atts_{$shortcode} filter. The shortcode_atts() function now accepts a third parameter — the name of the shortcode — which enables the running of this filter. All of the core shortcodes now pass this parameter.

This filter passes three things:

  1. $out — the output array of shortcode attributes
  2. $pairs — the array of accepted parameters and their defaults.
  3. $atts — the input array of shortcode attributes

Let’s look at what we can do with this. One thing is that you can dynamically set or override shortcode values. You an also define new ones, and transpose them into accepted ones. Let’s look at the “gallery” shortcode for example. What if there was a gallery of images that you would reuse. Instead of picking the images each time, you could have a plugin that gives that set of attachment IDs a shortcut name. Then you could do [gallery foo=my-gallery-name], which the plugin would convert to a list of IDs. Or, you could enforce a certain number of gallery columns on the fly. Let someone set it theme-wide, without having them go back and change their shortcodes.

What other uses can you think of?

Now, if you’re a plugin or theme author who provides their own shortcodes, you should immediately start providing this third parameter to your shortcode_atts() calls (since it is an extra parameter, you can do this without a WordPress version check). Maybe it’ll reduce the number of times people need to fork your code just to add an option to your shortcode!

WP Help 1.0

My WP Help plugin just got a huge update. Version 1.0 is really worth checking out. I’m quite proud of it.

WP Help

WP Help is a plugin for creating documentation for display within the WordPress admin. Many WordPress installs are customized, and it’s really helpful to have a centralized resource for documenting those features. You can create documents about creating content, editing content, moderating comments, or whatever you want! If you have clients who can’t seem to remember how to do X, you should install WP Help and document it for them. WP Help is powered by WordPress Custom Post Types, so you create content using the full WordPress editor.

Document Syncing

Oh yeah. This is the feature you’ve all been waiting for. If you have a standard set of help documents you want to use on multiple sites, this lets you do that. Create the documents, grab the (secret) sync URL for that site, and then plug that URL in to other sites. Those other sites will automatically pull down those documents, and keep them up-to-date (even handling new documents, deleted documents, renamed documents, and re-parented documents). Any internal links in the original document will be rewritten to be local to the destination WP Help install. So go ahead and use the WP internal linking functionality on your source site and know that those links will work on all the destination sites!

Menu Placement

The menu item for the help documents can now be placed in one of four locations:

  1. As a Dashboard submenu
  2. Top level, above the Dashboard
  3. Top level, below the Dashboard
  4. Top level, at the bottom

You get a live preview of this (yeah, I know, super fancy).

Menu Name

The menu name (and page title) can be changed. Just doubleclick the page title, edit it, and hit return. Boom. Again, this has a live preview.

Topics List Name

Likewise the topics list header can be renamed. Doubleclick, edit, return. Live preview.

Edit Links & Management Links

If you can edit help documents, you’ll get an edit link. When editing, there is a handy “Manage” link to jump you back to the documents management interface. Navigating in general has been improved quite a bit.

Dashboard Widget

There is now a simple dashboard widget, listing all of your help documents.

Better Default Access

A lot of you said that you have Contributor-level users who need documentation just like authors do. So now they can view documentation by default (there’s a hook if you want to change the capability required to view help documents).

Lots of Little Tweaks

There are numerous little tweaks to improve your experience. Check out out!

Roadmap

Things I’m considering:

  • Restricting individual documents to users with a certain level of access
  • Multiple sync sources

Any other ideas?

“The writer should be the one to click it”

The beauty of Web publishing, and the specific beauty of TechCrunch, is that the only barrier between bloggers’ overflowing brains and readers’ racing hearts is a publish button. And the writer should be the one to click it.

[...]

Over the course of our conversation, Tsotsis told me she viewed the act of writing the post as a sort of meta-comment on The New York Times’ antiquated editorial structure: “Look what I can do with my dumb little WordPress blog. You guys can’t do this. Watch,” she remembered thinking.

Andrew Beaujon @ Poynter

Whether you love or hate Alexia Tsotsis’ writing, one thing is certainly true: she’s no one’s monkey. And while a debate about the wisdom of making “Fuckers” the first word of a blog post would undoubtedly be entertaining, that’s not what I want to talk about. Tsotsis and Beaujon make two very interesting points that directly relate to WordPress and its effect on publishing.

WordPress is absolutely a tool that can (and given the state of the tools they were previously using, should) be used by Ye Olde Media Guarde. We’ve even made some steps toward supporting a basic editorial workflow with the Contributor role (which can submit posts for review, but not publish them). But using WordPress in that way is like using a computer to print a letter and then fax it to your recipient. It feels like an artificial restriction. We’ve empowered individuals to publish what they want to publish, when they want to publish. Reinstating the print media workflows of the last century very much feels like a step backwards. Writers got a taste of true publishing freedom. Readers got a taste of what it’s like to actually have a connection and conversation with a writer instead of just being delivered their words. We can’t pretend that didn’t happen.

One of WordPress’ user experience breaks from its competitors was its “Publish” button. Other software had a “Save” button and then a drop-down status selector. So you’d select “Published” from the status drop-down, and then hit “Save”. With WordPress, your post is always one quick click away from being shared with the entire world. It’s more raw, more immediate, and more emotionally satisfying. WordPress also instituted “Edit” links on the front end, which gave the same sense of immediacy to the updating process. As much as the old media has embraced blogging as part of their publishing strategy, they’ve not fully integrated its responsive and update-able nature. On the whole, old media “blog posts” feel like a place where statements of questionable truth go to die and never be corrected, clarified, or amended.

Web publishing is much, much more than print publishing with the web as a distribution network. As long as the old media treats the web as a pipe instead of an opportunity to modernize the way they publish, they’ll continue to be called “the old media”.

BRB. Leaving a voicemail with my editor so she can get this post published in tomorrow’s issue.