Expiry date for members

Hey @leifharmsen,

I’m glad the plugin will be useful for you. ??

I could add a hook in that occurs after the plugins base exclusion system where you can add additional logic.

It would pass you all the fields from the user record in the external database so that you could return true if you wanted them excluded and false if you didn’t.

This way it caters for future peoples problems that want different logic and allowed you to have complete control.

Let me know your thoughts,

Tom

That hook would be golden! I tried to figure out where I could add my own exclusion code hack but haven’t managed yet so yes, that hook would get me started.

In my case it isn’t an equality comparison. I have to check if a date is greater than now or not – so yes I think it will be ordinary for users to need their own custom logic and control. Everyone’s special case seems totally obvious to them, lol.

I’d be perfectly happy to just be able to enter SQL WHERE clauses to exclude records like:

“DATE(expiry) < CURDATE()”

To be as non-coder friendly as the rest of your plugin maybe some future version might include having a pull-down for the comparison operator, so instead of always checking for equality it could also check for “less than” or “greater than” or “not equal”. For my task at hand I don’t need anything that “user friendly” – I’d be happy to hard code my conditional and buy you a beer.

Hey @leifharmsen,

Agreed – could definitely be an add on for the future. I keep toying with the idea of investing a bit more in the plugin and creating a ‘Pro’ paid for version but the legwork in setting that all up is hard to justify.

Thanks for your positive attitude and your comments. It’s always great to hear another perspective.

For now I will plod along with the hook for you and I’ll write you some Pseudocode to help you get started with adding the hook to your setup.

I’ll try my best to keep you posted but feel free to check in with me in a week or so if you haven’t heard from me.

Thanks,

Tom ??

Cheers. And I paypaled you some beer money as my small token of encouragement. I miss drinking in England. I’ll raise a glass from our farm here in Canada. Stay safe.

Leif

Hey Leif,

Just wanted to say thanks for the beers!

If you’re ever back in England down Brighton way let me know and we can toast your project properly!

Just updating to say I haven’t forgotten about you and have seen your other thread but prob won’t be looking at this till the weekend but will at least update you on progress by end of Sunday.

Will keep your posted ??

I can share what I’ve tried so far

			// Next line hack by Leif for LIFT to exclude lapsed members and ineligible member types (0, 8 and 9).
   			$query_string .= ' AND member > 0 AND member < 8 AND DATE(expiry) >= CURDATE() ';

Unfortunately it doesn’t work. In fact, it doesn’t even seem to try to work. I can close my browser and reopen it and login, and it still appears to get my information from WordPress’s user record rather than from my external database. The connection to my external database tests correctly, the test data of the plugin’s connection test is correct, “Enable External Login” is checked, “Migration Mode” is not checked, “Disable Local Login” is checked.

When I add
error_log($query_string, 0);
to db.php I do see a query string from every login attempt in my log and the query string works as expected when I run it on my database directly. So the plugin appears to run but doesn’t make any difference, at least if the user has a record in the WordPress user table (that I wish would be ignored at every login. )

I’d share my query string but it might be saying too much about my external database structure in this public forum.

Because of my current test settings in my external database, the query string returns zero rows, so I would expect my login to be rejected. Instead it logs me in as administrator according to WordPress’ user table even though “Disable Local Login” is checked!

I’m determined to make this work but I am not familiar enough with your code or WordPress’ login mechanism to be able to diagnose this myself – so I’m stuck without reverse engineering everything. Let me know if you think you might know where it could be going wrong. Maybe give me things to try or check for. I am hoping that it is something obvious, or something in the newest WordPress that’s different and we need to adapt to.

Leif

• This reply was modified 4 years, 7 months ago by Leif Harmsen.

There is one other anomaly which just might be a related clue… I can log in with my email address but not with my username. My username is 1. I also tried with another user 10562 and that worked with both his email and username, so it isn’t failing because 1 is a number. I don’t really care about that because I can ask everyone to log in with their email address, but it might be a clue as to why my record won’t update from the external database. Might there be some reason having 1 as one’s username would gum up the works? Maybe it’s being wrongly cast as a boolean at some point or something like that?

I will do some more experiments.

I did more experiments and discovered that my code was breaking your plugin, surprise surprise. Apparently the plugin defers to the wordpress user table if it can not find a matching user in the external database – so I have to allow it to find my record, and only then decide not to log me in on account of some condition and some field in it after that – so I was excluding myself too soon. I was hoping that zero results from the external database query would simply just not let me log in. I can see why it might be a bad idea to leave it that simple – too easy to lock onesself out! So I still need to figure out where to add my conditions like expiry date.

Wordpress, or at least the Astra theme I’m using, has a field for expiry date when you edit a user. I don’t know if that’s core or not but if it is maybe I could populate that somehow using your plugin – if it were to do what I need.

Not being able to log in with the username 1 is also a curiosity, but not related.

Turns out the expiry date field in my wordpress site was just an imported custom field from when I originally imported the site content from Drupal – so it isn’t core, it does nothing and is no use for this.

So, it’s all about finding where, perhaps after authentication and before login that I can then query the old database to fetch the expiry field and member field of the user, and conditionally accept or reject login depending on those values.

Hey @leifharmsen

Just wanted to say I haven’t forgotten about you! Life’s been busy for the last week for a couple of personal reasons landing at once.

Am determined to look at this for you this weekend and will try my best.

Sincerely sorry for the delay as I know you’re keen to crack on. Hoping things settle down at some point over the weekend and I’ve tried to block some time.

Apologies again and I’ll keep you posted

Hey @leifharmsen,

Just a small update.

I’ve got a working copy of your feature.

I’m hoping to make another few small improvements to the plugin so to avoid users having to update twice I aim to release tomorrow evening or Monday.

Hope this works for you.

I’ve written some psudocode in documentation for the plugin using your example.

Basically it’ll look like the following:
————————————–
– exlog_hook_filter_custom_should_exclude

This hook allows you to add custom logic to exclude users.

I provides you with all the data for the user that is stored in the external database users table.
If you return true from this function it will prevent the user logging in, and returning false will bypass this
exclusion.

For example, let’s say your external users table had a field called expiry which stored a date. In this example we
want to block users if they login after their expiry date.

Adding the following to your functions.php would achieve this:

function myExlogCustomExcluder($userData) {
    return strtotime($userData['expiry']) < strtotime('now');
}
add_filter('exlog_hook_filter_custom_should_exclude', 'myExlogCustomExcluder', 10, 1);

———————————

If you’re interested to know what the code change was you can see the current code change here:
https://github.com/tbenyon/wordpress_external_login_plugin/commit/c20cb3d2b4ed887e9ffef87c31d1763c9b8f54d1

Thanks,

Tom

I’ve been super busy all weekend too. Thrilled to check in and see all the progress you’ve made and can’t wait to take it for a spin tomorrow. Will be in touch. Thanks for all your inspired work!

Hey @leifharmsen,

This feature has just been released in version 1.9.0.

I’ll mark this as resolved for now.

If you have any issues or further questions, please don’t hesitate to get back in contact here.

Kind regards,

Tom ??