shra

Are you sure?
I’ve re-viewed role filter – it works for me.
So high likely you may have another filters/options enabled that is why filter’s results are empty.
If you still have this issue – i need more inputs to help you with.

Hey, @yuvrajsisodia !
It should be fixed in v1.65.

Hi, @mypersonalwebmaster!
All options are there in the filter. If you have woocommerce installed it will show you “woocommerce?anonymous orders” option. Despite the title It works for both anonymous and logged-in users, because the option looks up “email”.
Mentioned by you “who have never logged in” is the “known date log-in” filter. This information isn’t provided by WP Core, it is provided by other modules. My plugin collects this information, but also it may use few other modules which may collect it too (if they are installed).
“Users that have not name but only username” I am introducing in v1.65.

Hi, @davidki!

This is not a standard WP message (you will not find this phrase in core WP code). For known plugins I could found it in loco-translate for instance.
My plugin doesn’t introduce a new permission levels, so it seems it is not possible to help you from my side without seeing what is on your end.

Hey, @wbenterprises!
Thanks for all those ideas.

Normally user deletion is a quick process, but you are right it may be hooked by 3rd party modules and the processing will take more time, and may as a result face to time-out.

It doesn’t cover many cases but I will try to implement it, at least this is an interesting task.

I’ve added one more filter (pending user) – v 1.64.
As for me it seems a bit excessive function, because you may remove all pending users as those who never login.
But it was easy to implement, so why not if this is needed for someone.

• This reply was modified 9 months ago by shra.

This is nice you’ve tried. Thanks!
Yes, for now this is only way to donate, but don’t worry.

Disable an account is not core feature, so method is always one – to add a marker to user’s metas. Disable User Login plugin uses _is_disable meta key with values 0/1. My plugin additionally creates a meta field with date of disabling and it is compatible now with plugin DUL. So when you disable/enable users via my plugin and DUL is active it will work like you disable/enable in terms of DUL as well (it updates _is_disable meta).

You can easily verify this –
1) disable one of users via my plugin
2) check user list here /wp-admin/users.php – you will disabled status in ‘Disabled’ column

This column is provided by DUL plugin so it means then for DUL this user is disabled as well.

I’ve added compatibility?with disable-user-login. Does it cover your needs?

Sure, it is possible to create the query constructor you described. It also requires to provide connection between WP_USERS and selected tables because we need to provide ON clause for each LEFT JOIN. But technically all these things are possible.

I just think plugin should provide simple, safe and limited experience for users. In other way we push users to become developers. ??

In context of adding compatibility with disable-user-login plugin, i may implement the feature even without adding a new flags as a part of ... been disabled filter.

YES : NO : IGNORE – about this thing i have the same feelings.

Hi, timmoser!
Yes, this is a good idea to do.

You know guys, starting from some moment it works as you wish, i just implement what you guess :).

I will keep it in my mind on next development iteration as a new feature, thanks.

I guess technically I can implement that. Currently some checks are made after main SQL request so that is why i implemented existing way. Another thing is that we can have new registrations during the process of confirmation and deletion, and program should know exactly what users are necessary to delete. But user’s ids list could be stored as, for example, JSON-encoded text in one single field. It has own limitation – a size of POST data. But usually it is enough big to keep the whole list.

I will keep it in my mind on next development iteration as a good idea, thanks.

Thank you, @fearzzzz! I found out what you meant. I hope now it is fixed. New version is uploaded (1.61)

In last update i rewrite it as next:

$confirmPeriod = (!isset($_POST[‘confirmPeriod’]) || $_POST[‘confirmPeriod’] <= 0) ? 1 : intval($_POST[‘confirmPeriod’]);

so as you see the value is filtered by intval func. You say “still exploitable”, could you share the exploit example, please?

Oh my god, guys, you are killing me ?? Ok, catch the next version 1.60!