A very common pattern used in WordPress core, plugins and themes is way of dealing with supplying arguments to functions and merging them with default values. This pattern is documented in the codex here and utilizes wp_parse_args() and extract().

What does it do? Well a look at the actual wp_parse_args function shows us that it’s a glorified version of array_merge. What array_merge does is combine two arrays into one, overwriting duplicate keys supplied by the first array. That’s exactly what you’d want right? You see if your function requires a value and none is set by the user, a default would be used. Merging the defaults with the user supplied arguments ensures that you always have your required values set.

As a matter of convenience extract() is often called straight after wp_parse_args(). Extract will take all the variables in an array and import them as individually named local variables based on the array key value. An example:

$my_array_of_settings = array( "my_setting" => "wonderful" );
extract($my_array_of_settings);
echo $my_setting; // prints "wonderful"

The problem with extract() is that it is also a potential vector for insecure behaviors since it will try to import every value that is contained in the supplied array. It also can result in unpredictable results. That’s not a good thing when you are not in full control of how arguments are passed to your functions (which is certainly the case for distributed plugins and themes). The alternative, and most advised practice is to avoid the use of extract altogether and just use other ways of accessing the values.

I’m not one to throw the baby out with the bathwater and what I really wanted was a stricter version of wp_parse_args(), one that will limit the variable set based on those defined in the defaults. Instead of importing all the variables in a supplied array, it will only import those that are also specified in the array of defaults. (This behaviour is actually what I was intuitively expecting from wp_parse_args in the first place.)

function custom_parse_args( $args, $defaults ){
	if ( is_object( $args ) ) {
		$r = get_object_vars( $args );
	} elseif ( is_array( $args ) ) {
		$r =& $args;
	} else {
		wp_parse_str( $args, $r );
	}

	if( is_array( $defaults ) ) {
		foreach( $defaults as $default_key => $default_var ) {
			$vars[ $default_key ] = ( $r[ $default_key ] ) ? $r[ $default_key ] : $default_var;
		}
	}
	return $vars;
}

So what does this do differently? Let’s compare this function with wp_parse_args. Let’s have an array with defaults and an array with our arguments, some of which the function is not expecting.

$defaults = array ( "title" => "parsing arguments test");
$args = array(
	"title" => "I was not expecting some kind of Spanish Inquisition",
	"unexpected_response" => "Nobody expects the Spanish Inquisition",
	"chief_weapon" => "fear and surprise",
	"three_weapons" => "fear, surprise and a ruthless efficiency",
	"ah_four_weapons" => "fear, surprise, a ruthless efficiency and an almost fanatical devotion to the pope",
);

$wp_parse_test = wp_parse_args( $args, $defaults );
$custom_parse_test = custom_parse_args( $args, $defaults );

If we now inspect the resulting variables, you’ll find that the wp_parse_args method leaves us with:

// var_dump( $wp_parse_test ); outputs:
array(5) {
  ["title"]=>
  string(52) "I was not expecting some kind of Spanish Inquisition"
  ["unexpected_response"]=>
  string(38) "Nobody expects the Spanish Inquisition"
  ["chief_weapon"]=>
  string(17) "fear and surprise"
  ["three_weapons"]=>
  string(40) "fear, surprise and a ruthless efficiency"
  ["ah_four_weapons"]=>
  string(82) "fear, surprise, a ruthless efficiency and an almost fanatical devotion to the pope"
}

But our custom function filters out the unwanted variables automatically:

// var_dump( $custom_parse_test ); outputs:
array(1) {
  ["title"]=>
  string(52) "I was not expecting some kind of Spanish Inquisition"
}

Because we better control what variables can be used inside the function, using extract() becomes a whole lot safer.

For even more control, you could even run data sanitization and validation checks on each variable before they are allowed to overwrite a default variable.

A very common requirement for membership sites is the ability to send a user that is logging in to a specific home page. With S2Member there are a couple of ways to accomplish this. I came across some solutions involving javascript, which I think is a bad idea for a number of reasons. I’ll share one method here that is relies on some server side magic instead. To implement this you’ll need to write a little bit of code and insert it in your plugin file, your theme’s functions.php or your s2hacks.php file.

The first clue to redirecting users after logging is the UI S2Member provides under ‘General Options’. There is a section called ‘Login Welcome Page’, which is what we’re after. Here S2Member gives you the option to select an existing page from a dropdown. We don’t want that option because it will be the generic welcome page for all user levels/roles. To send users to different pages based on their membership level, we can make use of the field below the drop down.

 Or, you may configure a Special Redirection URL, if you prefer. You’ll need to type in the full URL, starting with: 

http://

. A few Replacement Codes are also supported here.

It’s basically a text field that let’s you specify a url. The cool thing is that we can utilize dynamic variables in the url with replacement codes. The solution I’m using here involves using the %%current_user_role%% replacement code as a GET parameter in the url. What you get is a url that looks like

http://yourfabulousmembershipsite.com/?custom_welcome_page=%%current_user_role%%

The words custom_welcome_page can be replaced with a wording of your choosing (make it unique though) and the %%current_user_role%% will be dynamically replaced with the membership level of the user that is signing in.

For the next step, we are going to write the code that tells WordPress to interpret those parameters.

[php]function your_member_site_vars( $vars ){

$vars[] = “custom_welcome_page”;
return $vars;
}
add_filter( ‘query_vars’, ‘your_member_site_vars’ );[/php]

And now WordPress will interpret the parameter we’re using, we have to tell what to do when it is used next.

[php]

function my_login_redirect() {
if ( get_query_var( ‘custom_welcome_page’ ) ) {
$role = get_query_var( ‘custom_welcome_page’ );
// double check if user has that role
if( current_user_can( $role ) ){
wp_redirect( my_member_welcome_pages( $role ) );
exit;
}
}
}

add_action( ‘template_redirect’, ‘my_login_redirect’ );

[/php]

What the above code does is listen to the parameter custom_welcome_page in the url, if it  is found then it will try to redirect the user. To determine the page, we write another function that takes the membership level of the user and returns the appropriate url.

[php]function my_member_welcome_pages( $role ){

// Set the welcome pages in the following array

$welcome_pages = array(
‘subscriber’ => ‘http://www.yourfabulousmembershipsite.com/subscriber-welcome/’,
‘s2member_level1’ => ‘http://www.yourfabulousmembershipsite.com/level1-welcome/’,
‘s2member_level2’ => ‘http://www.yourfabulousmembershipsite.com/level2-welcome/’
);

if( $welcome_pages[$role] ){
return $welcome_pages[$role];
} else {
return ‘http://www.yourfabulousmembershipsite.com/your_default_welcome_page/’;
}
}
[/php]

These functions are the basic functionality needed to create your own custom welcome page redirects for your members.

Would you like to have a plugin with a simple user interface that does this for you? Drop me a line.

 

While working on a membership site I wanted to retrieve a user’s role by their user id, but I couldn’t find a quick function to do this. WordPress does provide the WP_User object which gives us quick access to all user information, including user roles. To get the user role by a given ID we can do the following in php:

[php]

function get_user_roles( $id )  {
$user = new WP_User( $user_id ); // this gives us access to all the useful methods and properties for this user

if ( $user ) {
$roles = $user->roles; // returns an array of roles
return $roles;
}  else {
return false;
}

}

[/php]

It’s useful to note that it’s possible for a user to have multiple roles, even though most sites and plugins don’t utilize this possibility. What if you want to check if a user has a certain role? We can write a simple function for that as well. In my case I wanted to check if they have the custom role of teacher (a conditional function).

[php]
function user_has_role( $id, $role = ‘teacher’ ){
$roles = get_user_roles( $id ); // retrieves an array of roles
if ( $roles && in_array ( $role, $roles ) ) { // checks if specified role is listed
return true;
} else {
return false;
}
}
[/php]

Since WordPress 3.3 a nice new drag and drop uploader was included. It works great because it has fallbacks for older browsers that don’t support the newer HTML5 api. Accessing the file uploader still requires bringing up the media uploader via the upload button. Wouldn’t it be even nicer if we could directly drag and drop our files into our WYSIWYG editor?

The newish wp_editor function also makes it easy to include additional tinymce editors for our plugins and themes. I was looking for a way to add the tinymce editor to P2 and include a quicker way to drag and drop files. Adding the editor is relatively easy now but and it even lets you add the media upload button to the front end, but I want to remove the need for clicking that button.

Possible solutions:

My first thought was to insert the new native uploader inline below the editor so that we could directly drop files into a dropzone without having to navigate to the media uploader. I’m sure it can be done, but it was going to take me too long to do it properly and cleanly.

My second idea was to look for existing plugins that could do all the work, but there don’t seem to be any functional ones in existence that are straightforward to implement and integrate. It also seems a bit overkill to include another uploader when WordPress already can do everything I need.

After that I thought about digging into the filereader api for HTML5 and making my own solution…but then I thought of a shortcut that would be the best of all worlds.

Providing you have the upload buttons enabled for your editor, it’s possible to detect a drag event when a file is being dragged into the editor and automatically fire the native media uploader.

The great thing about this is:

1. It streamlines the uploading process without adding loading scripts unnecessarily.
2. It removes one mouse click operation and feels more intuitive than navigating to the uploader manually.
3. It relies on the native uploader which deals with all the complex stuff, such as fallbacks, inserting the file into the post, setting parameters, attaching the file to the post and so forth. No reinventing the wheel!
4. It removes the need for a separate ‘drop zone’, which takes up space. Instead, the editor itself is the drop zone.

Implementation:

All we need is a few lines of javascript. What is needed:

– A way of detecting when a file is dragged into our editor that works across all modern browsers

– The id attribute of our editor

– A trigger event to activate the native uploader when a file drag (or drop) is detected. For this we need to know how to select the media upload button with a selector.

optional:

some extra magic to add some css styling during the drag and drop operation.

Part 2 will cover the actual code…which I haven’t written up yet. Want to see the final solution? Sign up to the newsletter and you’ll get a notification when it is published.

There’s a number of ways to retrieve the post id of a post, but what if your page has multiple loops and you want to retrieve the main post id of the page? In my case I wanted to insert social buttons only on the main content of the page. If you are using the_content filter to add the html for your social buttons, it will show every time any kind of post content is displayed. Some page designs often use several loops to display various pieces of content (especially front pages), so you could end up with an abundance of social buttons – not exactly ideal. My solution then involved checking to see if the currently outputted content was the main content of the page by comparing post ids.

So I looked to see if there was a simple way to access the main post id – even if we are inside a secondary loop. Surprisingly, there doesn’t really seem to be a function for this. The closest thing is a function called get_page_by_path, but that works just for pages. Another idea is to access the $wp_query global variable, but this can be altered when other queries are made. What we can do is store the ID in our global variable when we are certain that $wp_query contains the main post id.

[php]
function main_post_id() {
global $wp_query;
global $main_post_id;
if( is_singular () ) { // ignores index pages for posts, categories, tags, archives etc
$main_post_id = $wp_query->post->ID;
}
}
add_action( ‘wp_head’,’main_post_id’ );
[/php]

Now we can quickly access the post id anywhere on the page, even if you are in a custom loop.

[php]
ID ) {
// do stuff
}
?>
[/php]