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