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.
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…
Recent Comments