Intro to Post Formats in WordPress 3.1


WordPress 3.1 will introduce a simple new feature called “Post Formats” that should make theme developers very, very happy people. Although the feature is simple, in the hands of a creative designer it allows for some pretty major styling options with a single line of code.  If a designer also happens to have some minimal PHP savvy, it has some pretty tremendous creative potential.

Basically, Post Formats are just meta information and some front-end style additions to allow a theme author to customize individual posts both in “the Loop” and on single post pages.  Yes, it’s something that some theme authors have already been doing using categories or tags and some custom code — but this is easier and it also allows for some standardization and portability between themes which I think is the most important part.

At the time of this writing Post Formats is still in its early incarnation, so some things may change before the release of version 3.1.  That said, I think the feature is at a stage where we can start playing with it without much risk of major changes.

The basics:  Activating Post Formats

add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );

Post Formats in Publish Meta Box

That’s it!  That single line of code is all that’s needed to activate Post Formats in your theme.

Once active, a few things will automatically happen.

On the back-end, users will now be presented with a Format option in the Publish meta box of the post editor screen.

On the front-end, a couple of things happen. The post_class() function that most themes use to will start adding ‘format-‘ classes to each post wrapper and the body_class() function will add ‘single-format-‘ to the page body class.

A quick example of how to make use of this new class would could be as simple as this:

#content .format-default h2 {
   font-size: 32px;
   font-color: #333333;
}
#content .format-aside h2 {
   display: none;
}

In this example, we’re not doing much more than changing the title formatting of two post formats, but as you can imagine, this could be applied to every element of each post.

Supported Arguments

Post formats has just one argument.  The supported post formats.  Because this feature is intended to be standardized and portable between themes, custom formats are not an option. Currently supported (per the codex):

  • aside – Typically styled without a title. Similar to a Facebook status update.
  • chat – A chat transcript.
  • gallery – A gallery of images.
  • link – A link to another site.
  • image – A single image.
  • quote – A quotation.
  • status – A short status update, usually limited to 140 characters. Similar to a Twitter status update.
  • video – A single video.

Enable support for each post format by adding it to the array in add_theme_support.

Additional Functions:

At the moment, the post formats feature only brings one new function to the table:

get_post_format( $post->ID )

This returns the post format of the current post – very useful in a custom loop to take your customization’s further than you could with a pure CSS solution.

More Info

There’s already been a fair bit of discussion about why custom post formats aren’t being supported.  Frankly, the logic behind this is simple and solid:  the feature is designed to be portable and standardized.  Allowing for a custom option steps all over that logic — the instant ‘custom’ becomes an option, standards and portability go out the window.  As much as I’d like to see every feature in WordPress as customizable as possible, this is one case where I think it’ll be more globally beneficial to keep options broad but standardized.

If you can think of post formats that are missing, get yourself over to this trac ticket (#14746) and make your case for inclusion.

UPDATE:  Or join in here: http://wpdevel.wordpress.com/2010/11/11/list-of-post-formats/


Install Google mod_pagespeed with DirectAdmin


Earlier this week, Google released an open source Apache module to simplify the optimization of your content.  The module, mod_pagespeed, will do all sorts of magic like minify your JS/CSS and optimize images, and a handful of other optimizations that seem (from limited testing) to improve your servers performance considerably.

Google has provided a couple of RPM’s to help with installation, unfortunately, if you’re running DirectAdmin on CentOS, they won’t work.  DirectAdmin runs a compiled Apache with some slightly different defaults and installing using YUM or RPM will fail dependency checks.

In this article, I’ll explain how to get around the dependency issues and adjust your configuration.  I have to warn you that this is NOT something I recommend you do on a regular basis unless you’re an experienced Linux Admin, in which case you probably won’t need this tutorial. Overriding RPM dependencies can have some adverse effects on your system.  In this case we know most DirectAdmin / CentOS systems share a very similar configuration, so it’s not much of a risk.

Download a copy of the CentOS RPM or wget it from your shell:

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm <– 32bit
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_x86_64.rpm <– 64bit

Since you’re running on a DirectAdmin server, trying to install using YUM or RPM will fail dependency checks since Apache is built from source.  We’ll have to force the installation and make a couple of changes to our systems configuration files:

rpm -i –nodeps mod-pagespeed-beta_current_.rpm

vi /etc/httpd/conf/extra/httpd-includes.conf

And add the following to the top of the file:

#Google PageSpeed Module
Include /etc/httpd/conf.d/pagespeed.conf

Next you’ll need to edit your main httpd.conf file:

vi /etc/httpd/conf/httpd.conf

Find and remove the line:

Include conf/extra/httpd-deflate.conf

If you’d like to change the options for PageSpeed, it’s configuration file is located in /etc/httpd/conf.d/pagespeed.conf

Once everything is set, we’ll need to restart Apache and test to see if the module loaded properly:

service httpd restart

and

apachectl -t -D DUMP_MODULES | grep pagespeed

If you get the following output, everything should be installed and functioning properly:

Syntax OK
pagespeed_module (shared)

You should also check any .htaccess files you may use and remove any instances of ‘setoutputfilter’ as this will probably override what mod_pagespeed is doing.

There you have it!  Load up a copy of FireFox with the PageSpeed installed and check out how your score has improved.  In my case, with all other caching disabled, I went from a score of 60 to an 82.  Not a bad improvement if you ask me!

 

rpm -i --nodeps (the right version of mod_pagespeed).rpm