Wordpress

Displaying custom field data from a WordPress page, post, or custom post type is very easy. Simply access WordPress’ global query and grab the custom field you need!

global $wp_query;
$postid = $wp_query->post->ID;
echo get_post_meta($postid, 'customFieldSlug', true);

WordPress 2.9 introduced a new useful feature that has saved me several headaches since its release. Your posts, pages, comments, and custom post types now have a “recycling bin” that temporarily stores content that you’ve deleted. These items remain there for 30 days before WordPress automatically purges the trash.

Sometimes 30 days proves to be more time that you need to store trash items. Sometimes you might want to keep these items longer. Some people might even find it useful to keep these trash items indefinitely. After browsing through the Codex, I came across an option made available to use which allows us to control the length of time items are kept in the trash.

To turn off simply add the following code to your wp-config.php file:

define('EMPTY_TRASH_DAYS', 0);

To shorten the time items are cleared, 10 days for example, simply change the second variable:

define('EMPTY_TRASH_DAYS', 10);

Or to increase the time, say… 60 days:

define('EMPTY_TRASH_DAYS', 60);

As I mentioned before, leaving this option alone will default to 30 days.

My favorite addition to WordPress 3 is the ability to easily add custom post types. I’ve utilized this feature in nearly all my new projects, and now I’m not quite sure what I ever did without them. One thing that wasn’t included in their release was the ability to easily sort these post types in the WordPress admin. By default the admin sorts them alphabetical by title, which isn’t ideal for most situations. The easiest way to achieve this without using one of the various sorting plugins out there is by applying a filter to WordPress’ parse_query hook.

You can sort by all of the typical WordPress query variables. Below is an example to sort your custom posts in reverse chronological order by post date, as you’re accustomed to with WordPress’ default Post type.

add_filter( 'parse_query', 'order_by_query' );
function order_by_query( $query ) {
    global $pagenow;
    if ( is_admin() && $pagenow == 'edit.php' && isset( $_GET['post_type'] ) && isset( $_GET['post_type'] ) == 'your_post_type' && isset( $wp_query->query['orderby'] )  ) {
        $query->query_vars['orderby'] = 'date';
        $query->query_vars['order'] = 'DESC';
    }
}

Simply add the above filter to your themes functions.php file, plugin, or alongside wherever you register your custom post type.

Edit: As Bruce noted below in the original example I neglected to include making the list actively sortable. The above function now includes this. Thanks, Bruce.

Today Automattic announced they are releasing a plugin called Jetpack for WordPress.org self-hosted websites. This plugin will bring in many features which before today were only accessible on WordPress.com hosted blogs. Among some of these features are:

• WordPress.com Stats (Previously available via standalone plugin.)
• Twitter Widget (Already several 3rd party variations out there, but this is the same one available to WordPress.com blogs.)
• Gravatar Hovercards
• WP.me Shortlinks
• Sharedaddy (Again, most dot.org folks were using  AddToAny or some other variation.)
• LaTex (for the uber-geeky)
• After the Deadline (More grammar, spelling, styling assist.)
• Shortcode Embeds (For embedding videos and other media.)

From Automattic:

In this spirit, we have great news. We are now making the power of WordPress.com available to almost all WordPress blogs, regardless of where they are hosted.

With Jetpack, a new plugin from Automattic, people not on WordPress.com can now access features that depend on WordPress.com. Jetpack also provides convenience features that don’t use the cloud, but are now easier to install, or were unavailable as plugins before.

 

Matt Mullenweg explained the reasoning behind their decision to Open Source these features:

The dot.org users can get the best of WordPress.com without giving up control, which might be the future of open source in general. …If you’re on WordPress you’re part of the family, it shouldn’t matter if we host you or not.

Thanks Matt!

I’ll be testing out this plugin over the next couple days and will come back with some thoughts and opinions for those not already familiar with the Jetpack lineup.

If you’re like me, you like to try and keep everything in one place when developing for WordPress. That’s what initially attracted me to the WP Developer Assistant plugin. Download and install this plugin and have access to many great developers tools:

• Query your WP database without SSH or another browser based GUI tool (like phpMyAdmin).
• Upload themes, plugins, or other files without needing to switch over to your FTP client. (Great tool for when you’re not at your main workstation and find yourself without an FTP client.)
• Quick access a list of WP filters and hooks.
• Enable error mode for your admin users, while suppressing them for other users.
• Quick access to your PHP config info.
• Quick access to a full list of defined options and constants, with the ability to easily edit serialized content.

You’re not discovering anything new here, just brining it all under one roof. Check it out and let me know what you think.

Since WordPress 3.1 dropped yesterday I’ve had several people ask me about a (not-so) unusual memory error when trying to upgrade. WordPress 3+ packs a bit more under the hood compared to it’s 2.x predecessors, so if you’ve previously upgraded to one of the v3 dot releases then theres a chance you’ve come across this before.  The error will look something like this:

The quick way to attempt a fix is to add the following to your WordPress installations wp-config.php:

define('WP_MEMORY_LIMIT', '64M');

I believe by default WordPress defines the WP_MEMORY_LIMIT variable as 32M, so in most cases this should quickly resolve your problem.  If you’re running WordPress Multi-User (or a very heavy WP site in general) then you might need a bit more, which might require some fine-tuning to your servers php.ini file to increase the servers PHP memory limit.  Most shared hosting doesn’t allow this so ask your hosting provider. If you have access to this file simply add or update the memory_limit variable to match or exceed that of WP_MEMORY_LIMIT.

If after you define the WP_MEMORY_LIMIT variable you’re still receiving this error then you might want to check out the TCP! Memory Usage plugin. This will give you some brief statistics on your servers and WordPress installation memory limits and usage, and indicate your memory requirements.