With the Members plugin you can pretty easily set up roles that are appropriate for your particular application. On a recent project using a multisite install of WordPress, however, I came across a slightly annoying issue — the Members plugin is designed to not allow you to delete the default role or the role you're currently logged in with. In the case of the default role, you need to first change the default to something else, then you can go back and delete the current default role. All members who are assigned the current default role will be assigned the new default role when you delete the old one. So if your default was Subscriber and you make the new default be a custom role you created, say Member, when you delete Subscriber everyone with that role will be reassigned to Member.

If you're logged in and your account has the custom role Owner, you won't be able to delete that role for obvious reasons. You'd need to log out and log back in as another role with delete_roles permissions. The issue I ran into is that with Multisite, when I'm logged in as a Super Admin I have no ability to delete roles. I don't want to have to create an account for each site, give that account the delete_roles capability, and then log out and back in everytime I want to make a change.

The solution? A small modification to the edit-roles.php file, located in /plugins/members/components/. Change as follows:

To

Now super admins will be able to delete any role except for their own (Administrator) and the default role.

If you prefer, you can download the modified file here and simply replace the existing one:

Downloaded 90 times

Wondering how to change the default role for a particular site when you're using Multisite? You don't have the option on your General Settings tab like you do on a single site install. To do it in Multisite go to your Super Admin menu and click on Sites. Go to the site you want to change and click on Edit. Then scroll down the screen full of settings and you'll find Default Role with a text box next to it showing your current default. To change it type the name of the new role you wish to substitute using the role name, not the role display name. For example, you might have created a role called Paid Members but the role name might be paid-members.

The email could not be sent. Possible reason: your host may have disabled the mail() function.

But weirdly enough the email COULD be sent, and in fact it was.

For those who simply want the solution, here you go. For those who are curious about what caused the problem, it’s explained below.

Solution:

In the Mailpress plugin folder open /mp-includes/wp_pluggable.class.php and replace the following code:

Code block

/**
 * wp_mail() - Function to send mail
 */
if ( !function_exists( 'wp_mail' ) ) :
	function wp_mail( $to, $subject, $message, $headers = '', $attachements = false )
	{
		MP_Pluggable::wp_mail( $to, $subject, $message, $headers, $attachements);
	}
endif;
 
/plugins/mailpress/mp-includes/wp_pluggable.class.php

With this modified version:

Code block

/**
 * wp_mail() - Function to send mail
 */
if ( !function_exists( 'wp_mail' ) ) :
	function wp_mail( $to, $subject, $message, $headers = '', $attachements = false )
	{
	$result =	MP_Pluggable::wp_mail( $to, $subject, $message, $headers, $attachements);
	if($result!=0){
	return $result;
	}
	}
endif;

That’s it, you’re good to go.

Now, for those who are wondering why this happened. WordPress allows programmers to override it’s wp_mail function and several others by simply declaring a function with the same name. It does this by wrapping the wp_mail( ) function in the following condition:

Code block

if ( !function_exists( 'wp_mail' ) ) :

What this means is, if there isn’t already a function called wp_mail, then go ahead and proceed with creating one. But if there is, then skip this. Since your plugin and theme files get loaded before the file where this code is (/wp-includes/pluggable.php starting at line 233), your version of wp_mail already exists and hence it’s the one that gets used.

Mailpress takes advantage of this to define it’s own version of wp_mail — that’s what you just changed in the code above. And it works great. Except for when it comes to the reset password process. The reason is this: When you click on the reset password link in the first email, you are being sent to wp-login.php with two pieces of info. appended to the URL — a unique reset password key and your user login. The wp-login.php file does some magic to verify that key and generate a new password which is inserted into the database and then emailed to you. But before it generates the new password, it checks to make sure that it can actually send it to you.

In wp-login.php starting at line 259 you’ll find the following code:

Code block

if ( $message && !wp_mail($user->user_email, $title, $message) )
  		wp_die( __('The e-mail could not be sent.') . "<br />\n" . __('Possible reason: your host may have disabled the mail() function.') );

It looks to see if a message has been created and if so it calls the wp_mail function. The ! — which is a PHP operator meaning NOT — means that if wp_mail() doesn’t return some value, then something is wrong so stop the process (otherwise you’d never get your new password).

And that’s where the bug is. WordPress expects wp_mail to return “true” if it was successful. Mailpress’s version of wp_mail returns the number of emails sent. So when you hit the login page and WordPress does it’s check to see if it should go ahead and reset your password, it never gets back a response and it fails. By making the slight tweak to return the result, it gets the response it’s looking for and all is good.

Hope that helps a few of you out.

The one file class allows you to easily paginate any database results with all of the above navigation options. Integrating it into WordPress was a matter of tweaking the URL parameters it was based on. With that done I simply included the class in a custom plugin I’m writing for this project, declared a new global instance of the paginator class (so that I could access it on my templates) and that was it, all set.

I’ve attached the modified file as a download. The original site has great instructions on how to use it as well. The section of the site where I’m using it isn’t publicly accessible but I’ll stick a demo up here shortly showing how to use it in WordPress.

Short version is that the way it was written, when you first load a page with a form it gets output on the page. When you submit via ajax, the request goes back to that same form function, and checks to see what the result is. The result is passed to a hidden iframe, then that content is used to replace the existing form HTML.

The issue is that what is being passed to the iframe INCLUDES the jquery call to make it all work, wrapped in a document.ready() call. When it is passed to the iframe, IE8 doesn’t see jquery as being loaded — it treats the iframe like a totally separate page. The solution was to split the jquery stuff out on ajax pages so that it is loaded only the first time the page is loaded, and all that is sent to the iframe is the actual form.

An updated copy of form_display.php is attached. Just download, replace the one in your plugin folder and you’re good to go.

If you have access to the WP database however, you are in luck.

Using PhpMyAdmin or your dbase tool of choice, access the new WordPress table and browse the wp_users table – there will be one record, for the new admin user.

WP uses a function called wp_hash_password() to generate the passwords. So I just did an echo of wp_hash_password(‘password’) to see what it would store in the database if you used “password” as your password. Output is: $P$BWRXG..rmf7CMNWqugvFlwWj.7pwQl/

So just paste that in the admin password field and then you can login to WP using “password” as your password and then change it from your Profile link. *Make sure you do change that password immediately for security reasons.

Mailpress is a great plugin that continues to develop into a more commercial grade product even though it is still completely free. While it isn’t as robust (yet) as PhpList or some of the other options out there, it does integrate entirely with WordPress and has some really great functionality. What it suffers from most is a lack of clear documentation and some residual quirks in programming. One of the most annoying of those quirks is the “Don’t use automatic upgrade” warning it always shows you on the plugins page. Why does it say that? Because your custom mail templates are stored in the plugin’s folder and would get overwritten if you updated automatically. That lovingly crafted “Welcome to my site” template you labored over for hours would be gone.

Looking for a workaround to that issue also brought up another issue: On a WPMU or 3.0+ site with multiple blogs, I don’t want the various custom templates for each blog being shown to all the others. Site 1′s templates shouldn’t be visible to Site 2, and vice versa.

The latest version of Mailpress (v 5.0.1) includes a sample config file and has some typically crpytic notes indicating you can use this to move your template files somewhere else within the plugin folder structure, but isn’t too clear on how to do it and offers no help for getting them out of the plugin and into the theme folders. But with a little hacking, I was able to work that one out.

Take the mailpress-config-sample.php file in the main Mailpress folder and rename it to mailpress-config.php. It’s mostly some hard to follow comments with a bit of code at the bottom. Replace that code with the following:

Code block

/*NCG CUSTOM CODE TO PUT MAILPRESS THEMES IN EACH BLOG'S THEME FOLDER */
 
add_filter('MailPress_theme_root', 'MailPress_theme_root', 8, 1);
 
function MailPress_theme_root($path) {
 
	$folder = 'mail-templates';
 
	$my_path = get_theme_root() . '/' . get_template() . '/' . $folder;
 
	return (is_dir($my_path)) ? $my_path : $path;
}

*The code above is updated with the improved version by Mailpress, see comments below.

What we’re doing is looking to see if the current theme has a folder in it called mail-templates (feel free to change that to whatever you like). If it does, then Mailpress will look in there for theme folders. If it doesn’t, then Mailpress defaults to the standard themes that come with the plugin (and are located in the plugin’s mp-content folder).

Now all of my email templates are right alongside the rest of my themes, safe and sound from future upgrades and my various site users only see files that are applicable to them.

Newport Creative Group

1300 Park Newport Drive
Newport Beach, CA 92660

tel: 949-734-0758
fax: 208-493-4001

Problem and my fix are documented there. In a nutshell, the plug-in won’t work correctly when you’re attempting to show a single post by ID #. Fix is to add in the following code at line 123:

/*NCG edit */
if( $instance['post'])
$args['p'] = $instance['post'];