Web Development

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.

Importing large MySQL dumps can be difficult, especially depending on your web host and the level of access to your MySQL server. phpMyAdmin is great for exporting (“dumping”) your existing database, but due to most hosting limitations doesn’t necessarily foot the bill for importing. Enter BigDump. BigDump is a Staggered MySQL dump importer developed by Alexey Ozerov, and made available under the GNU General Public License. From the BigDump site:

Staggered import of large and very large MySQL Dumps (like phpMyAdmin 2.x Dumps) even through the web servers with hard runtime limit and those in safe mode. The script executes only a small part of the huge dump and restarts itself. The next session starts where the last was stopped.

Why use BigDump?

To restore the very large backup of your mySQL database (or a part of it) into the new or the same mySQL database. You can’t access the server shell and you can’t import the dump using phpMyAdmin or any other scripts due to hard memory resp. runtime limit of the web server.

What you’ll need to use BigDump

• The BigDump file
• The MySQL dump from your existing database.
• Existing database server, database name, username, and password information.
• FTP access to your web server.
• A text editor to exit the BigDump configuration file.
• Common knowledge about PHP, MySQL, phpMyAdmin, FTP and HTTP are a plus.

How to use BigDump

STEP 1: Setup BigDump

The first step will be to configure BigDump to connect to your database.

Open the bigdump.php file which you downloaded in your favorite editor. (TextEdit for Mac, or Notepad for Windows will work fine.) The only lines required for BigDump to function are those for the database configuration, which you will see below:

// Database configuration
$db_server   = 'localhost';
$db_name     = '';
$db_username = '';
$db_password = '';

Here you will need to enter the database name, usermane, password, and server. If your MySQL server is located on the same server as your web services, simply leave this set to localhost. Otherwise, enter the server address for your SQL server.

Now save the file and upload it to your web server via FTP. (I suggest creating a separate directory for BigDump file, as we’ll also be placing your SQL dumps in this directory.)

STEP 2: Upload Your SQL Dump to the Web Server

Your MySQL dump file has to be in the same directory as BigDump, so place your dump in the same location that you just uploaded bigdump.php.

STEP 3: Execute the BigDump Script

• Access your BigDump file at: http://www.yourdomain.com/dump-directory/bigdump.php
• Locate the MySQL dump file in the list of available databases.
• Click the “Start Import” link.
• Wait for the import to finish. Do not close your browser window/tab while it’s running.
• Once finished a confirmation will be displayed (displayed below).

From here you should be done and your imported database should be ready to use. Use phpMyAdmin (or any other tool) to verify the database tables have been successfully imported.

REMEMBER: FOR SECURITY DELETE THE BIGDUMP.PHP FILE AND SQL DATABASES FROM THE WEB SERVER WHEN DONE.

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.