maximinime

I know all that. My point is that your plugin does not tell users when their existing forms are broken because of a name field.

This is a really common problem, and the developer apparently won’t fix it. You need to edit the file really-simple-captcha/really-simple-captcha.php and add

@chmod($file, (fileperms($file) & 044) | 0600);

immediately before the two unlink calls.

More info: It only affects the error class because it uses extends. See this answer on Stack Overflow.

It’s definitely some PHP weirdness. require_once is allowing the file to be included twice. This is a known issue when a file is included/required once in more than one place and the case of the line include is different in the two places e.g. require_once 'File.php'; and require_once 'file.php';.

But, This one is being included twice by the same line in wp-includes/pluggable.php! Meaning it can’t possibly be that known issue because that line uses constants and a string literal to call the file which can not change between calls.

This one got me, too. I think it’s some kind of internal PHP bug, not your usual noob double-including mistake. Searching the web, everybody else’s problem was failing to use only require_once, or having two different copies of the file with different names or paths. I found a different cause and solution.

The reason I think it’s internal to PHP is because:

1. I verified that there was only one file defining that class in the entire project.
2. I know that file was only being included once because I put if (class_exists('phpmailerException')) die('HOLY CRAP'); at the top of it. So it could not be included/required more than once without me knowing.
3. I wrapped only the phpmailerException definition in a
   if (!class_exists('phpmailerException')) {...} block, which solved the problem!

If the file was being included more than once, it would die with a fatal error as soon as it tried to define the main PHPMailer class again, but it never did. The only conclusion I could arrive at was that PHP was compiling the class twice in the same file.

It works for me now, too. I don’t know what would have caused the issue for me before. I know I cleared the cache and deactivated and reactivated it a couple of times.

I still think it would be better UI if the plugin had its own settings page rather than the extra row.

If you can still log in to the admin area, go to settings > permalinks and click save changes (without making any changes). This forces WP to recreate all the internal rewrite rules. This fixed the issue for me.

No worries Andy. Yes, my point was he should be using the newer function.

I had this issue and sent a fix through to barinagabriel, you shouldn’t experience this issue once using version 1.3.4, nor need to use his work-around.

Better still, in mailusers_any_user_profile_update(), instead of removing the elses, change the lines like

update_usermeta($uid, MAILUSERS_ACCEPT_*_META, 'false');

to:

add_user_meta($uid,  MAILUSERS_ACCEPT_*_META, get_option('mailusers_default_*'), true);

obviously, replacing the *. Then the default is only set if it doesn’t already exist.

Also, update_usermeta() is deprecated.

@barinagabriel I noticed this broke again for me in pro version 1.3.1, and I could not see the admin bar in the front end at all.

It seems you were addressing an issue where, if a user was in a role set to hide the admin bar, being in another role that had it set to show wouldn’t make it reappear. I have provided a corrected function so that being in any role that explicitly shows the admin bar, makes sure it will always show:

function wppb_show_admin_bar($content){
	global $current_user;

	$adminSettingsPresent = get_option('wppb_display_admin_settings','not_found');
	$show = null;

	if ($adminSettingsPresent != 'not_found' && $current_user->ID)
		foreach ($current_user->roles as $role_key) {
			if (empty($GLOBALS['wp_roles']->roles[$role_key]))
				continue;
			$role = $GLOBALS['wp_roles']->roles[$role_key];
			if (isset($adminSettingsPresent[$role['name']])) {
				if ($adminSettingsPresent[$role['name']] == 'show')
					$show = true;
				if ($adminSettingsPresent[$role['name']] == 'hide' && $show === null)
					$show = false;
			}
		}
	return $show === null ? $content : $show;
}

We didn’t end up needing it for our project, so I don’t know. I’m fairly certain this is caused by MySQL 5 not converting the string value to 0. So if you’re testing with 5+, you should be fine.

One more problem: The plugin cannot be uninstalled. It’s requireing a premium file without first checking if it exists.

It’s much better, but it still puts the full domain the image field. The right place to add this information is at display time (many plugins get this wrong and even WordPress itself it not so great at URLs).

For example rather than saving https://dev.site/path/to/image.jpg to the database (which will be wrong when the site goes live), save only /path/to/image.jpg then when displaying it with your function you prepend the WordPress address, becoming https://live.site + /path/to/image.jpg.

I don’t think you understand. The wp_mail_content_type filter is fired for every email send, and can be different each time. Your code attaches to phpmailer_init as soon as the first text/plain is encountered. It isn’t reset after each email is sent, it stays attached. If another email is being sent that is already html, the function that is still attached to phpmailer_init fires anyway.

Imagine a doorman. He asks everyone if they need help with their bags when he opens the door. As soon as one person says “yes”, he will help everyone. If the next person says no, he will try to help them anyway, because one person said “yes”.

wp_mail($email, $subject, $message, $message_headers);
...
add_filter('wp_mail_content_type',create_function('', 'return "text/html";'));
wp_mail($different_email, $different_subject, $html_message, $message_headers);

The first call sends a plain text email that is converted by better emails. set_content_type() switched on converting for the first email, and left it on for all subsequent emails. The second call will now try to send its own html mail but better emails will still try to convert it.