Here’s something that comes up for me pretty often: depending on what I’m trying to do, I sometimes need plugin functions to run (or not run) simply based on which admin page the user is visiting. Here’s the WordPress function that will give you the title of the currently loaded admin page:
get_admin_page_title()
So, if you only want to run a bit of code on the “Edit Posts” page, you’d put together a conditional statement like this:
if(get_admin_page_title() == 'Edit Posts'){
//do something fancy
}
Post meta is easily one of the most useful features in WordPress from a developer’s perspective. Adding custom content to a post provides the ability to accomplish countless goals quickly and easily.
Sometimes, it makes sense to give the user access to a post meta field – for example, if they need to add a thumbnail url to a post, they’re probably going to need to access to those post meta fields. Other times, having the post meta field visible is only likely to confuse the visitor. One (extremely popular) place that I’ve seen this is the All in One SEO Plugin. All in One SEO is wildly popular, and does what it claims well. It provides a few extra fields, and a nice, easy to use interface to get at them. Here’s what it looks like when you get started:
Fantastic. It’s attractive, easy to use, and works well. So we save our post, and then later on, we go back to edit the meta description. Here’s what we get:
At this point, its pretty clear what’s going on if you understand the inner workings of WordPress – AIOSEO has saved our values to custom fields, so now they’re showing up there. However, most users dont understand, or even care about how AIOSEO works, or what custom fields are. All they know is that strange stuff is showing up, and they’re not sure where to edit their meta keywords, because they’re showing up in 2 places. Most people have the gumption to just change one and see what happens – but there will always be users who get scared and decide they want to email you about the issue, or worse, just uninstall the plugin and move on.
The WordPress developers, fortunately, thought of this. In fact, they store all kinds of stuff that they don’t want the user to see in custom fields – things like the last time the post was edited, who is currently editing it, and a few others. A quick look at the database, reveals this:
Notice a trend? The mysterious custom field key values are prepended with an underscore. Give it a try – enter a new custom field from the edit-post page, and enter a name that starts with an underscore – like _thumbnail, or _meta_keywords. Hit “Add Custom Field”, and it disappears – but if you check the database, its right where it should be.
Now get out there and start hiding things from your users!
In one of many, many strokes of genius, the WordPress core developers threw in a bit of code to allow users (ok, other developers) to define a custom user table, and a custom usermeta table for a WordPress install.
In it’s simplest form, you can point your WordPress user table at that of another blog on your server. Doing so means both blogs (and why stop at 2?) share user information: passwords, usernames, author bios, etc etc. If you’ve got a site that requires numerous different, separate WordPress installs (think something along the lines of wired.com), but the same authors often write on many or all of them, this is a great, and easy solution.
Yes Sir. Just slap this code in your wp-config file:
define('CUSTOM_USER_TABLE','new_user_table');
define('CUSTOM_USER_META_TABLE', 'new_usermeta_table');
It’s pretty self explanatory from there – just define a custom user table, and a custom usermeta table, and you’re good to go. Want your users to share login info across different blogs, but be able to have a different bio for each one? Define a custom user table, but leave the default user_meta table. Everything stored in the users table (ID, login, password, nicename, email, url, and display name, among other things) will stay the same across all blogs. Everything else (nickname, user level, First Name, Last Name, and many other things), will be blog specific.
Here’s a very cool little tidbit I found today (strangely enough, I found it in the bbpress codebase, while working on a bbpress plugin..) WordPress keeps track of which function/filter combinations are registered, along with which action hooks have been called at any point. If you’re having trouble trying to figure out which action hook you should use to run some code for your plugin or theme, give this a try (on a test install, of course).
As far as I can tell, this holds every currently registered function/filter combination, and all the relevant information. I can’t quite figure out exactly what determines which filters this grabs – I’ve tried calling it from a few places, and the results are slightly different, but I can’t seem to find a pattern. I initially assumed that you wouldnt be able to see about admin side hooks from the front end, but this isn’t the case. At any rate, you get lots of information from anywhere. Not getting the info you want? Call it from somewhere else! This is a great debugging tool if you’re having trouble with plugin incompatibility – it gives you a list of the filters and actions being called,the matching functions that are working on them, the priority specified for each hook call, the accepted args, and even the order in which same-priority-level hooks are called. An example:
[the_title] => Array
(
[10] => Array
(
[wptexturize] => Array
(
[function] => wptexturize
[accepted_args] => 1
)
[convert_chars] => Array
(
[function] => convert_chars
[accepted_args] => 1
)
[trim] => Array
(
[function] => trim
[accepted_args] => 1
)
)
)
This is a small snippet I pulled after displaying the contents of this variable in the footer of a theme. As you can see, the referenced hook is a filter, specifically “the_title”. It has 3 functions attached to it: wptexturize, convert_chars, and trim. Each one is at priority level 10 (which is the default), but they are called in the order listed. Each accepts 1 argument.
If you want to have a look yourself, display the contents of wp_filter with this code snippet:
<?php global $wp_filter; print_r($wp_filter); ?>
This is going to dump the contents right to the screen, so you don’t want to do it on a live blog. As with any use of the print_r() function, the results will be formatted nicely in the source code – but not in the rendered html.
Justin over at justintadlock.com made a post a few days ago about how to preset text in the WordPress post editor. It’s a great post, with an interesting filter detailed. In the comments, somebody mentioned that they’d like to be able to preset custom fields as well – something that seems like it shouldn’t work (Custom fields need a post id to work on, and new posts dont have a post id). Yesterday, the workaround hit me like a slap in the face while I was in the shower – so I decided to package up this, along with the original code that Justin published in a plugin.
It’s not the most elegant piece of code in the world, but it works on all the installs I’ve tried it on. I’ll try to put up a post detailing how it works soon, but in the meantime, feel free to download the plugin and give it a try.
This isn’t a terribly difficult task – it’s incredibly common, and it’s covered multiple places in the codex. So why am I writing about it? A few months ago, I was tasked with customizing a plugin – one that someone else wrote. I need to add some options to it, and their code was baffling to me. I could see that they were using custom options, but I couldnt understand how they were being set – it was like the author just made some form fields and hoped for the best.
What was happening is referenced here (Right in the codex – apparently the last place I thought to look). My first instinct has always been to post forms on an admin page to itself, then handle checking for the $_POST values, and creating/updating the appropriate options. As is often the case, WordPress makes it even easier than that:
I wont get into the boring details – you can look at the codex page for that – but pay special attention to the hidden fields you set up:
<input name="action" type="hidden" value="update" /> <input name="page_options" type="hidden" value="new_option_name,some_other_option,option_etc" />
Not too tough to understand – the first line tells the system that we’re going to be updating, and the second line lets WordPress know which fields we want to create/update. These, of course, need to match the “name” attribute of the input elements up above.
I posted a few days ago about the very cool functionality of maybe_serialize(), and its relation to WordPress options. I often store arrays in options, because they help keep the database free of unnecessary clutter, and they make your plugin even easier to use (from a developers view). I was a little worried that this “page options” trick would prevent me from saving arrays – but alas, WordPress saved the day again:
<input type="text" name="fruit_colors['apple']" value="red"> <input type="text" name="fruit_colors['carrot']" value="orange"> <input type="text" name="fruit_colors['banana']" value="yellow">
Just make a form field an array, like you would with a set of checkboxes (by adding [] after it). Pass in the proper values to the page_option hidden field, like so:
<input name="page_options" type="hidden" value="fruit_colors" />
This can get pretty interesting – a few days ago I used to to loop through categories and associate a string with each one – you can do the same for posts, days of the week, whatever suits your plugin.
So there you go. You’ve got yourself an option without any tinkering with $_POST variables, or checking if you need to update or create an option. WordPress even takes care of serializing it for you. What a world…
Ralph over at ForTheLose.org wrote up a great post on how to use custom fields in wordpress a few days ago, and I thought I’d expand on it with another feature that I use for clients quite often. Custom fields are a great way to store extra post information, and they can really make for some more interesting layouts.
Sometimes, however, they can be a little much for a non-tech savvy client or user to handle – they’ve got to choose the right custom field from the dropdown, or type it in properly, or it won’t work – and what if you’ve got a few specific option values you’d like them to choose from for the custom field? Sometimes it’s just too risky to expect the user to be able to handle it.
With this in mind, I started looking into how to modify the Add Post and Edit Post pages (ok, they’re really the same page). As it turns out, its not too terribly difficult to add in a few options of your own on the post page, giving the user attractive, easy to use access to more advanced features of your theme or plugin. A few examples:
This one was a fun project for me – I had a client who wanted to have a different sidebar on his “testimonials” page (he was a consultant). Now, I started to just set up a new post template for him, but I realized that he really wasnt going to want to call me every time he wanted to add a new testimonial – that would be ridiculous. I had really helped sell him on the idea of using wordpress so he wouldn’t need to call me a few times a month to make small changes to his website – so forcing him to do so to change his testimonials wouldnt be acceptable.
After giving that some thought, I decided to make another widgetized sidebar for use with the testimonials page template. This way, he could add text widgets to just that sidebar. I got to work, and got it set up, and decided that wasn’t quite right either – what if down the road he decided he wanted to show those testimonials on a sales page, or some other page I hadn’t thought of? He’d be out of luck. I decided what I really wanted to do was set up a number of sidebars (I ended up with 6), and allow him to choose the sidebars (it was a 3 column theme) for each page. Custom Fields were the perfect fit for the job, but that meant he’d have to remember the name of each of the sidebars when he wanted to change them. A custom post options box seemed just the right fit. And it did – he was really excited about the functionality, and I was excited to have learned something new.
Another project tasked me with creating a wordpress theme site for a client. He wanted each theme post to have a number of fields relating to its layout and structure – things like number of columns, if it was widgetized, etc. I decided that the easy way would be to just put the info into the post body, maybe in some custom tags or something – but wouldn’t it be cool if users could search by this info? I got to work. What I ended up with was a custom post options box with all the relevant theme info – dropdowns and checkboxes, which removed any possibility of error from user input. The client was happy, and as always, I had a good time doing it.
Before we get to how to actually implement this, a word of warning: with great power comes great responsibility. In this case, you’ve got great power to annoy your users – if you’re releasing a plugin with minor functionality that probably doesnt need a decision made on a per-post basis, it’s probably best to leave it off of the post page. There is no sense in cluttering and slowing down the post page if it isn’t completely necessary.
The actual implementation of this isn’t too hairy – we’ve basically got 4 parts:
First things first – we’ve got to reserve a spot on the oh-so-exclusive edit post page. Here’s how we do it:
add_action('admin_menu', 'my_post_options_box');
function my_post_options_box() {
add_meta_box('post_info', 'Post Information', 'custom_post_info', 'post', 'side', 'high');
}
First things first – we hook into the admin_menu action, with our callback function my_post_options_box(). With this callback function, we initiate the actual box – with the add_meta_box() call. Add meta box works like this:
add_meta_box(‘id’, ‘title’, ‘callback’, ‘page’, ‘context’, ‘priority’)
Now we’re going to actually display the options on the page:
function custom_post_info() {
global $post;
?>
<fieldset id="mycustom-div">
<div>
<p>
<label for="cpi_dropdown_options" >Dropdown Options:</label><br />
<select name="cpi_dropdown_options" id="cpi_dropdown_options">
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 1' ); ?>>Option 1</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 2' ); ?>>Option 2</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 3' ); ?>>Option 3</option>
</select>
<br />
<br />
<label for="cpi_text_option">Text Option:</label><br />
<input type="text" name="cpi_text_option" id="cpi_text_option" value="<?php echo get_post_meta($post->ID, 'cpi_text_option', true); ?>">
</p>
</div>
</fieldset>
<?php
}
Nothing too fancy going on here – but a couple of important points – we grab the $post global at the top – we do this so we can check against already stored values in the database (for editing posts instead of creating them). The entire section is wrapped in a fieldset, a div, and a paragraph – this ensures that the display matchces the rest of the boxes. Other than that, its a pretty standard form, we’ve got a dropdown menu and a text box waiting to be populated.
We’ve had the user set the options, all that is left is to retrieve them on “Save Draft” or “Publish”, and put them where they really belong – in custom fields. This is a little trickier than I expected it to be (and maybe I’ve made it too difficult. If somebody can think of a way to simplify this, please let me know).
add_action('save_post', 'custom_add_save');
function custom_add_save($postID){
// called after a post or page is saved
if($parent_id = wp_is_post_revision($postID))
{
$postID = $parent_id;
}
if ($_POST['cpi_dropdown_options']) {
update_custom_meta($postID, $_POST['cpi_dropdown_options'], 'cpi_dropdown_options');
}
if ($_POST['cpi_text_option']) {
update_custom_meta($postID, $_POST['cpi_text_option'], 'cpi_text_option');
}
}
The first thing we do is hook into the save_post action. This is called on both saving and publishing, so we should be covered. Our custom_add_save takes a post id as input from the save_post action, and we need it to tell wordpress where to save our options.
Next, we need to figure out if the post id we got matches a real post, or just a revision. Revisions are stored in the database right alongside posts, with their own id and all – so we use the wp_is_post_revision function to determine if we’re working with a revision. If we are, wp_is_post_revision conveniently hands off the id of the parent post for us to use.
Now we’ll check to see if our options were posted. If we find a $_POST option matching one of our fields, we use that to update the custom field relating to it – but since we have to do this a few times, I’ve sent the actual work of updating the custom fields to another function – update_custom_meta(). Here, we check if the post_meta (custom field) is already set – if it is, we just update it. If it isn’t, we add a new one.
// ===================
// = POST OPTION BOX =
// ===================
add_action('admin_menu', 'my_post_options_box');
function my_post_options_box() {
add_meta_box('post_info', 'Post Information', 'custom_post_info', 'post', 'side', 'high');
}
//Adds the actual option box
function custom_post_info() {
global $post;
?>
<fieldset id="mycustom-div">
<div>
<p>
<label for="cpi_dropdown_options" >Dropdown Options:</label><br />
<select name="cpi_dropdown_options" id="cpi_dropdown_options">
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 1' ); ?>>Option 1</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 2' ); ?>>Option 2</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 3' ); ?>>Option 3</option>
</select>
<br />
<br />
<label for="cpi_text_option">Text Option:</label><br />
<input type="text" name="cpi_text_option" id="cpi_text_option" value="<?php echo get_post_meta($post->ID, 'cpi_text_option', true); ?>">
</p>
</div>
</fieldset>
<?php
}
add_action('save_post', 'custom_add_save');
function custom_add_save($postID){
// called after a post or page is saved
if($parent_id = wp_is_post_revision($postID))
{
$postID = $parent_id;
}
if ($_POST['cpi_dropdown_options']) {
update_custom_meta($postID, $_POST['cpi_dropdown_options'], 'cpi_dropdown_options');
}
if ($_POST['cpi_text_option']) {
update_custom_meta($postID, $_POST['cpi_text_option'], 'cpi_text_option');
}
}
function update_custom_meta($postID, $newvalue, $field_name) {
// To create new meta
if(!get_post_meta($postID, $field_name)){
add_post_meta($postID, $field_name, $newvalue);
}else{
// or to update existing meta
update_post_meta($postID, $field_name, $newvalue);
}
}
?>
And there you have it. Quick, go make something interesting!
As you may have noticed in a post I made a few days ago about widetizing wordpress plugins, I mentioned that we needed to serialize our variables before we created them as options in wordpress. As it turns out, this isn’t the case – WordPress does it for you when you go to update or create an option. This morning, while reading a post on wpengineer.com about wordpress options, I noticed that in their sample code, they weren’t serializing arrays or objects before creating them as options. Michael, the author, set me straight on why this is ok.
As it turns out, WordPress is one step ahead of me. Maybe_serialize() is called a number of times throughout wordpress, relating to these items:
So there you go. Use all the arrays and objects you want in post meta, user meta, and options – throw caution to the wind, and put them straight in. WordPress will handle the boring stuff.
The quick version? Include wp-load.php and wp-admin/admin-functions.php in a file in the plugin directory, and point your cron there. For those of you with nothing important to do, a long winded explanation:
I ran into a project a few days ago where the client needed a simple plugin put together – read an xml file, pull some information from it, and turn it into a post. Initially, the client wanted to just write straight to the database, but considering we’ve got access to a number of functions perfectly suited for the job, I knew things would be much easier if we turned it into a simple plugin, and ran the built in functions from the admin side.
The plugin came together quite nicely – RSS read, categories created, post inserted, all like a charm. It occurred to me at that point that the client wanted this to run automatically at set intervals – he wanted to schedule a cron job to handle it. However, since the functions I needed to run exist on the admin side, I assumed I’d have to jump through some serious hoops to get a cron to run it.
I formulated a plan, and was all ready to implement it – the plan was to access wp-admin/options.php with the proper get parameters to run the function. It turns out, using curl, you can set a cookie, and then use it to access another page – very cool (big thanks to this post from Russell Heimlich for that; I’m sure more thorough documentation is out there, but his is the post I found).
I still wasnt crazy about the idea though – the extra input with the cron meant more work for the client, more possibility for things to go wrong, and more time spent on support for me. So I decided to see if I could just include the right files from outside the admin section, and poof – it worked. Here’s how it works:
You’ve got to include 2 files to get access to admin side functions: First, wp-load.php. wp-load.php gets everything set up, and fires up wordpress. However, we’re calling this function from the plugin folder, inside the content directory (as opposed to the admin directory) – so when wp-load is called, we’re not going to be in the admin section, and we’re not going to get access to those functions. On the bright side, we also don’t have to deal with WordPress forcing you to login. Since we still need those admin functions, include wp-admin/admin-functions.php. This loads up the admin side and gives us access to the admin functions – and we’re set to go.
So that’s it. Include those 2 files, call wp_insert_post() (or whatever you need to call), and make the client happy.
Off topic – if you’re tired of expensive web hosts, I’ve got a friend who is starting to host for people inexpensively: check out his post on cheap web hosting here.
This probably isnt something that comes up too often for the average user – your URL is your identity – so switching them isnt a great choice. In client work, however, this comes up all the time – development work takes place locally on your computer WAMP/MAMP, or on your server, where the client can keep an eye on things.
Once its ready, however, you need to move the site to their live server, and you need it to work right, and in a hurry. Oftentimes the client site is already live, and they’re just pushing a redesign out – you need things to not go wrong at this stage. Even as a personal user, there are a number of things that can go wrong while moving a site to a new URL, and nothing is less satisfying than figuring out why your site wont work after the move.
First, you need to understand how wordpress works – this might seem silly, but I’ve had a number of clients who can’t really conceptualize it – simply because they’ve never really worked with web applications before. WordPress obviously runs on a database – mysql. While it would be nice to just be able to move files over to the new server, the database must come along too. The database stores all of your posts, pages, and comments, as well as any settings that you’ve made during the setup process. It also stores some important options – most importantly, your blogs URL. That’s not really within the scope of this post, so the quick version is this – using your database access tool (I like Sequel Pro when I can get external database access, though nearly all hosting setups come with PHPMyAdmin) you need to dump all the wordpress database tables, and import them into the new host’s database. After that is done, you can put your files (all the wordpress core files, along with your theme, of course) on the new server.
The one file you’ll need to make sure to update is wp-config.php. You need to make sure that the host has been changed to match your new site’s database settings, and you need to make sure that your database username, password, and database name are all properly updated.
At this point, your blog should be working – but theres a problem – when you load it up, you’re immediately redirected to the old blog url.
To get around that, you’ll have to get into the database. WordPress blogs hold nearly all of their settings in a table called options (note – the default name for this table will actually be wp_options, so you’ll have to tack on your database prefix, which is found in wp-config.php, to the front of options to find the right table). There are 2 main options that need to be changed – the first has an option_name of ‘siteurl’, and the second is ‘home’. Once you’ve changed these 2 values, you should be able to go to your site at the new url, and login as you normally would.
There are still some problems that you can run into after this point. The first, and most common relates to your upload directory. Often, after moving to a new url (or moving to a new host), you’ll start getting a permissions error when you try to use the image uploader. This happens because of a field in the options table called “upload_path”. The upload path specifies where to store your uploads (obviously), but when wordpress is installed, this is automatically generated relative to your filesystem (not web) root. The easiest way to fix it is to go to the Miscellaneous settings page (Under the settings menu on your dashboard), and change the value there to ‘wp-content/uploads’.
This last piece is a little tricky, and can be dangerous – so please – BACK UP YOUR DATABASE before you try this. It’s not very hard to mess this up, and its very hard to fix (unless of course, you’ve got a backup lying around). If you’re moving a blog to a new url, but the old URL had a significant amount of post content on it, you want to make sure that all images now properly link to the new server. WordPress uses full image paths to link to images inside of posts by default, so if your old url (or the files on it) dissappear, you’ll end up with lots of broken images on the new one. Also, you want to make sure that any internal linking you did inside of posts is maintained.
To get all our old image and link urls properly updated, we’re going to use a mysql find and replace function. Heres how it looks:
update [table_name] set [field_name] = replace([field_name],'[string_to_find]','[string_to_replace]');
Lots of thanks to this page for teaching me this in the first place. It has saved me hours.
Here’s how I’d use this mysql snipped to change all the urls in my post content on this blog, if I were moving it to a blog found at http://www.someblog.com/petersnewblog.
update wp_posts set post_content = replace(post_content,'http://yourcodegarage.com/blog/','http://www.someblog.com/petersnewblog/');
A quick rundown of what we did there – The table we want to work with is wp_posts, and the field is post_content. So we’re taking every instance of
http://yourcodegarage.com/blog/
that is found in the post_content field of the wp_posts table, and replacing it with
http://www.someblog.com/petersnewblog/.
This replaces partial strings, so every time an image used to link to
http://yourcodegarage.com/blog/wp-content/uploads/2009/03/someimage.jpg,
it now links to
http://www.someblog.com/petersnewblog/http://www.someblog.com/petersnewblog/wp-content/uploads/2009/03/someimage.jpg.
The same goes for links.
Thats it – good luck!
Recent Comments