joelhardi

I’m closing this one out, feel free to start a new thread if you can identify whether there’s an issue.

OK, so this is not as impossible as it initially appeared. But … I won’t claim to fully understand WP roles/capabilities or why in hell the core team decided to serialize PHP arrays and jam them into database columns, instead of adding roles/capabilities tables like any reasonable person would. (What I mean is, the values in the database wp_usermeta table are stuff like ‘a:1:{s:6:”editor”;b:1;}’ and ‘a:1:{s:10:”subscriber”;b:1;}’.)

So, below is a patch that adds the constraint to only delete users with role containing “subscriber”. I tested it and it works for me, can you try it (on a backup of course for safety) and provide any feedback?

diff --git a/htdocs/wp-content/plugins/user-spam-remover/user-spam-remover.php b/htdocs/wp-content/plugins/user-spam-remover/user-spam-remover.php
index 3113ef6..94040c7 100644
--- a/htdocs/wp-content/plugins/user-spam-remover/user-spam-remover.php
+++ b/htdocs/wp-content/plugins/user-spam-remover/user-spam-remover.php
@@ -591,8 +591,11 @@ class UserSpamRemover {
            "LEFT OUTER JOIN ${pre}comments AS c ON u.ID = c.user_id ".
            "LEFT OUTER JOIN ${pre}posts AS p ON u.ID = p.post_author ".
            "LEFT OUTER JOIN ${pre}links AS l ON u.ID = l.link_owner ".
+           "LEFT OUTER JOIN ${pre}usermeta AS m ON u.ID = m.user_id ".
            "WHERE c.user_id IS NULL ".
-           "AND p.post_author IS NULL AND l.link_owner IS NULL ".
+           "AND p.post_author IS NULL ".
+           "AND l.link_owner IS NULL ".
+           "AND m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%subscriber%' ".
            $this->getUserWhitelistSQL()." ".
            "AND u.user_registered < DATE_ADD(NOW(), INTERVAL -$daysGrace DAY) ".
            "GROUP BY u.ID${limit};";

If you have no idea what to do with this patch (sorry, I would just attach the file if this forum had that feature) let me know and we can figure out some other way for me to send it.

This is too much of a hack and too big of a change to add to the plugin (sorry, blame WordPress core and their silly antipattern data model) but the patch should hopefully solve your problem.

Thanks for your interest in the plugin, I like your idea.

I haven’t done any serious development on this plugin in years, I’ll see if there’s an easy way to implement what you’re suggesting.

Sorry for the late reply, I don’t check this site often.

Sure, glad you like the plugin, thanks for the details. Sorry for the late reply I don’t check this that often.

That first error message is kind of a mystery, I put it in the code in a place where I didn’t think it should arise. Can you see if the users were actually removed or not? (It may be that they were but I’m guessing not based on your first statement)

Re: the activity log I can’t guess what the filename issue is … make sure you use a valid absolute UNIX path to specify the log directory. The plugin runs the PHP function realpath() and then checks that it’s either a valid directory that exists, if not it returns that message.

Do you have PHP logging to a file? Or do you see any PHP error messages onscreen? If so then that would be helpful.

Hi, sorry for the late reply, I don’t really monitor this message board.

There’s no real way to do what you’re asking for — it would mean removing previously seen pages from the remote user’s browser cache.

The real solution (and you’ve maybe seen this on other sites, but not realized how it works) to “break the back button” is to simply disable all HTTP caching of your /wp-admin/ pages, so they’re not stored in the browser cache in the first place.

That’s outside the scope of this plugin.

To point you in the right direction, if your web server is Apache, you could put some rules into a .htaccess file in the /wp-admin/ directory that instruct Apache to send HTTP response headers instructing the browser not to cache anything. Basically, this means sending “no cache” and an expires date in the past. For example, I copy/pasted this but it should work:

FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control “max-age=0, no-cache, no-store, must-revalidate”
Header set Pragma “no-cache”
Header set Expires “Tue, 20 Jan 2009 20:00:00 GMT”
</ifModule>

You would want to put this in /wp-admin/.htaccess and not in your root .htaccess, because otherwise it would disable all browser caching for your whole site, which is probably not what you want.

(Other webservers like Nginx can also be configured to send whatever HTTP headers you want to control browser caching behavior.)

This plugin doesn’t block or interfere with HTTP requests in any way.

Thanks for your interest, I do think you’re misunderstanding what “logout clear cookies” means. This plugin clear all cookies on the domain. It does this when the user logs out.

Read the code if that’s unclear, this is a literally a one-liner plugin.

If you’re asking for a plugin that magically reaches across the interwebs and removes cookies from a user’s hard drive because they close a browser window, that is impossible.

If you want to change a cookie’s 10-day expiry, you can set the original cookie with whatever expiry you want. Here’s one way to do that in WordPress.

Yes, thanks for the question. When I originally wrote the plugin, the WordPress database code was extremely primitive. For example, it didn’t use transactions with COMMIT and ROLLBACK to ensure consistency of the database.

As far as I know that’s still more or less the case. I stopped contributing to WordPress core years ago.

The code you linked to doesn’t appear to be ACID at all. For example it looks like it imperatively deletes posts, then links. What happens to the posts if the call to wp_delete_link fails? What happens to the rest of the program state? Keep in mind it was only recently that WordPress core stopped using the ancient PHP mysql interface. When PHP5 came out in 2004!

Anyway … the purpose of this plugin is maintenance, not security or abuse prevention. It’s for removing/pruning orphaned or unused accounts. It doesn’t remove users who have associated posts/comments/links.

Your idea sounds interesting, however that’s really a policy question (should I permit a user on my site if they’re on some blacklist?) that’s beyond the scope of this plugin. There are a lot of potential side effects and other security implications that would occur if a site owner decided to allow a third-party (the blacklist operator) to effectively delete users on their site — really, across a network of websites. RBLs had their day 15 years ago but nowadays there are better techniques to prevent abuse. Not something I’m personally interested in pursuing at this time but I wish you luck if you do.

Can you provide more information?

You do realize the plugin only clears cookies that are set on the domain of your WP install, right? … i.e. “siamsmileshop.com” in your case … or whatever you have the PHP constant COOKIE_DOMAIN set to.

You can use your browser’s developer tools to monitor what cookies are set on your domain as you go from page to page.

I’ll close out this ticket, please provide more information if you’d like to file a bug report. Thanks!

If you have the backup log file enabled, all you have to do is run the SQL commands it contains to re-insert the users into the database.

You can do this using the mysql command from the command line, or a GUI database client or tool like phpMyAdmin. Your choice.

There’s a Q/A in the FAQ with some more info.

Hi,

Not sure what you’re trying to accomplish, and I’m not familiar with WooCommerce, but I have a couple of thoughts, for whatever they’re worth.

If all your users have got a specific value in the postmeta table and you want to exclude these users from being deleted, then what users do you *want* to delete? And if a spam/bot account registers on your site, wouldn’t they have this same postmeta value set?

You’ve added a subselect into the query — I obviously can’t profile or test your query but I remember having to do significant query optimization when I originally developed this plugin, so I’d just draw your attention to that, there may be a problem with your query. It looks like your query would grow very large with the size of postmeta table.

A super-easy thing to do if you can write a SQL query to accomplish what you want is just to run the query periodically, or in a cronjob.

Hi, thanks for your question.

The answer is “I think so” but I haven’t tested it with multisite or domain mapping.

This plugin clears all cookies that are set on the COOKIE_DOMAIN, which I can see is defined by WordPress for multisite in wp-includes/ms-default-constants.php according to this logic:

  if ( !defined('COOKIE_DOMAIN') && is_subdomain_install() ) {
    if ( !empty( $current_network->cookie_domain ) )
      define('COOKIE_DOMAIN', '.' . $current_network->cookie_domain);
    else
      define('COOKIE_DOMAIN', '.' . $current_network->domain);
  }

But based on this link, it looks like when you use domain mapping you’re supposed to define COOKIE_DOMAIN manually in wp-config.php to the root domain name — this is where the codex page says to add define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']); to wp-config.php.

Anyway, I don’t totally understand your situation, so here are a couple of scenarios. Suppose your site is example.com and you have got domain-mapped sites like foo.example.com and bar.example.com:

• when a user logs out of foo, if COOKIE_DOMAIN is set to foo.example.com, then the plugin won’t clear cookies set on bar.example.com
• when a user logs out of foo, if COOKIE_DOMAIN is set to example.com, then the plugin should clear all cookies on example.com — I think this is what you want? … if so would need to make sure COOKIE_DOMAIN is set to example.com. In this situation though, there’s going to be a collision and users won’t be able to have active logged in sessions with foo.example.com and bar.example.com at the same time

If we aren’t talking about subdomains at all, and your domain-mapped sites have totally different names, then there is nothing this plugin or anything else can do to clear cookies on a different domain. Keep in mind that this plugin, WordPress, *any* website can only set and clear cookies on the domain that it is running. This is all controlled by the security model of the browser. Like if google.com had the ability to access cookies set by facebook.com, it would be anarchy! So this plugin and any plugin can only unset cookies on its own domain. Not sure if that is relevant to your question about affiliate cookies or not, just thought I’d mention it. Only the user can clear third-party cookies in their browser, you can’t do this from the server or using JavaScript.

Thanks for the idea and interest in the plugin.

I’ll push a version 0.2 that uses get_option('siteurl') instead of WP_HOME.

‘siteurl’ is the value the user puts in the General Settings screen as “Site Address (URL)” or sets using the WP_SITEURL constant. See here.

I think it makes a little more sense than WP_HOME that I was using since some people opt to put their WordPress files in a non-standard location.

If you have any other thoughts/ideas just let me know.

For how to restore users, there’s some more info in the FAQ.

The restore file is basically a text file containing a bunch of SQL commands. If you are familiar with mysqldump then it is the same format. You basically just need to run this file against your database and it will re-insert all the users who have been deleted. One way to do this is just to use the mysql command from the command line, this is this example in the FAQ:

mysql your_wp_database < userspamremover.restore.sql

Alternately if you are using a MySQL admin tool like phpMyAdmin, I think the majority of those have a way to upload and execute a SQL file. The main thing to know is that it is just a standard file full of SQL commands so you can just google something like “how do I run a SQL file using [whatever tool you use]”.

I can’t help you with your last problem unfortunately, the plugin doesn’t have any capability to tell whether an email address is good or likely to be fraudulent. In my day job I do some work with Emailage, which is a company with a web service that does this.

If all you need is a simpler rule, like only allowing registrations from @somedomain.com, that’s probably a pretty simple function to create to block all other domains and not allow them to register. Or if you wanted to remove these users on the backend, you could run a SQL command like this:

DELETE FROM wp_users WHERE user_email NOT LIKE '%@somedomain.com';

(note I did not test this query!)

That’s what the plugin already does, it deletes users who haven’t left a post, comment or link. In the current trunk see the SQL statement at line 590.

If you ever want to contribute code feel free to send a patch. Right now the code is just hosted here in the www.remarpro.com subversion repo.