anemos2k

Hi Tom,

You are correct about your Test button assumptions. However, on refreshing the page, shouldn’t this error disappear?

Here are two links helping with the MS SQL installation on a MAC. The first one is the oldest one and uses Virtual Box (need to install Windows on it and then SQL server)
https://database.guide/how-to-install-sql-server-on-a-mac-with-virtualbox/
However, the second is using Docker container and MS SQL for Linux!
https://database.guide/how-to-install-sql-server-on-a-mac/
The second article also provides links for a free SQL management tool under Mac.

I would still be very interested in implementing your plugin functionality in my environment.

Best regards
Panos

Hi Tom,

Family life tends to do that, it’s perfectly normal! 🙂

I think that I can delay the WordPress user login functionality till there’s an admin section that deals with the described problem.

Again, thank you for looking into that as well as suggesting a part-time solution in case I had a deadline. You are very considerate! In case I start to run out of time I might send you a quick message asking for the possible changes in functions.php or wp-config.php, if you don’t mind.

Best regards
Panos

Hi Tom,

Thank you for your prompt response!

I do believe that the problem described above is a general one. Many developers choose not to delete completely users but to just deactivate them. In that sense, they can always refer to the user’s historic data without creating orphan records in the database.

Now back to the plugin.
I think that adding an optional field could solve the problem. All users existing in the external database would be granted a login and be copied on the local db except if the plugin user has specified that there is an extra field on the external db defining the user’s login capability or not. This extra field would have to have just two states (as you very well mention), true/false or 1/0, true or 1 allowing the user to login, false or 0 disallowing it.

The same functionality could also be implemented by the user role defined in the external db (as you also very well mentioned). In that case, on the plugin settings on the role pairing screen, you could present just a check box next to the drop-down list with the external db roles where the user would check the roles that do not grand a WordPress login.

In both scenarios, those users should not be copied on the local db and should be removed or better marked as inactive if they were already existing there.

Regarding the SQL query, I think that it could be useful. However, since it would require a developer to deal with it (and the returned PHP array), it would appeal to a much more limited audience. Maybe you should consider it as a possible add-on but definitely not being part of the main distribution of the plugin and the problem that you are trying to solve which is: Allow authentication using an external database.

Thanks again for taking the time to look into this!

Best regards
Panos