joelhardi

Thanks for the report! I’ll update and repackage WPSCMin.

You were correct, WordPress core made a change to the API starting in version 4.3.0.

Anyway, it was a pretty easy update to make to the plugin and I just pushed a new version 0.9.9 that fixes the problem where the new user gets a bogus registration notification email with “Password: both” and is unable to complete site registration and set a password.

So please update to the new version and let me know if it solves the problem.

Note that if you have any users who have registered and never set their password, they can still set a password by using the standard WordPress “lost/forgot password” function. So if you have a number of users like that, you could send them each an email to let them know there was a problem on the site and give them the URL to reset their password.

Thanks for the bug report! I gave you credit in the changelog.

I am going to file a couple of feature requests/patches with WordPress core because the way this API is implemented in WordPress requires unfortunate copy/paste coding to alter the notification behavior. The result is that when core changes the API, it breaks lots of plugins. Also, the wording of the initial “Welcome” email that new users get could be improved.

OK, I’ll look into it further and see if I can replicate. It looks like there was a change in core that is causing side effects for plugins. Shouldn’t be too hard to fix if there’s a problem and then I’ll update the plugin.

It’s definitely good that core is no longer emailing out passwords in plaintext.

Sure, hope you figured it out!

Please refer to the documentation, the FAQ and to previous threads on the topic. I tried to write that error message to be as self-explanatory as possible.

If your WordPress install isn’t using MySQLi then the plugin is designed to throw that exception and tell you to use it. The old PHP MySQL extension is unsafe and should not be used.

Could you elaborate on the issue you’re seeing? The plugin still works fine for me with all versions of WordPress going back several years.

Please provide debug/trace information if you think there’s a problem with the plugin.

Please also be sure to read the system requirements and make sure your PHP and MySQL configurations are correct and that you aren’t doing something unsupported, like running the plugin on multisite or bbpress.

It’s not a problem with the plugin. It could be a conflict with a separate plugin or something else you’ve done to WordPress.

Let me know once you resolve the issue with your install, patches are welcome.

Please refer to the sticky topic about the 0.9.8 release, the last couple of resolved threads, the 0.9.8 release notes, or the installation instructions.

I’m not familiar with WooCommerce, someone else may be able to weigh in.

The plugin checks for users who have no comments, posts or links associated to them.

Without knowing anything about WooCommerce I’d guess that User Spam Remover would remove those users. It does back up everything that it deletes to a log file in SQL format, so that users can be restored.

FWIW I did update the readme to suggest adding the WP_USE_EXT_MYSQL line near the top of wp-config.php with all the other DB settings.

In fact it can be included anywhere except at the very bottom of the file. After wp-settings.php is required in (the very last line) it will have no effect.

I’m going to close out this issue as resolved. I can’t replicate in any supported environments. Am assuming you’re either not using the PHP mysqli extension or haven’t assigned adequate MySQL privileges to your database user. We can reopen and keep going if you still think it’s something else.

I can confirm that the plugin does require the ALTER and CREATE privileges to create its indexes (happens only on initial activation, not on upgrade). For everyday use only SELECT, DELETE are required. Of course basic WordPress use is going to require all of these privileges anyway, but I added this detail to the readme.

Also, when adding the line:

define(‘WP_USE_EXT_MYSQL’, FALSE);

to wp-config.php to tell WordPress to use mysqli you can put it pretty much anywhere in the file except at the very bottom of the file where you aren’t supposed to edit anything. i.e. add it anywhere above this line:

/* That’s all, stop editing! Happy blogging. */

Yeah I know, WordPress probably should just have that line say:

/* DO NOT EDIT BELOW THIS LINE */
/* Seriously do not do it! */
/* After wp-settings.php is included it is game over for you! */

But it doesn’t. ??

Personally I just put WP_USE_EXT_MYSQL next to all the other DB settings near the top of the file.

Yeah, sorry, the www.remarpro.com system is pretty primitive. You have to append a revision number, 0.9.1 (the last version to use original mysql extension) is here.

Did you get the new mysqli message in 0.9.8.1?

FYI PHP 5.5 deprecates the old mysql extension, so you will start getting PHP warnings if you upgrade PHP at some point and don’t switch to mysqli.

0.9.8.1 release just pushed.

There are no changes to function, just an explicit check for WordPress mysqli support and a friendly error message on the Admin screen to inform you when your WordPress installation has not been configured to use mysqli … so you need to do something about that if you want to use this plugin.

For developers: This is just a simple check against the $wpdb->use_mysqli property, which is part of WPDB.

I just pushed a new version 0.9.8.1. No real change in functionality but if you upgrade it’ll at least tell you more explicitly whether your WordPress installation is configured to use mysqli or not.

I’ve been trying but am unable to replicate your issue so far. For instance I’ve been testing using a MySQL user with only these limited permissions:

MariaDB [(none)]> SHOW GRANTS FOR ‘wordpressuser’@’localhost’;
+——————————————————————————————————————+
| Grants for wordpressuser@localhost |
+——————————————————————————————————————+
| GRANT USAGE ON *.* TO ‘wordpressuser’@’localhost’ IDENTIFIED BY PASSWORD ‘*175ECC8C35D7F9BF97A0C3AF85F765C26B23’ |
| GRANT SELECT, INSERT, UPDATE, DELETE ON wordpressdb.* TO ‘wordpressuser’@’localhost’ |
+——————————————————————————————————————+
2 rows in set (0.00 sec)