I use the core WordPress filters so there should be no ill effect for you unless the plugin you are using has broken core filters or actions.
It sounds like from your other question that you’ll be re-writing the only functionality my plugin uses wpdb directly so it shouldn’t have any impact here either.
In short, it should work fine if the other plugin you are using has correctly integrated with WordPress.
If you do have any issues I’m happy for you to share them here and I’ll see if I can help 🙂
Thanks,
Tom
Thread Starter
kevent
(@kevent)
I think your idea of pulling the user information from the external database into the WordPress db is an unique idea. So that other plugins won’t break. Very resourceful.
Reviewing some of the code, it does look like it requires all mapped user table fields to be present in the external database. If those fields are not present, then that would be a problem. Some non-essential data that might not be in the external database could have some default value inserted into the local WordPress DB as a solution.
There’s also a case where the different user fields might be in different external user tables and databases.
And also the case where the external database does not store the plaintext password or a password hash, but instead stores some type of password specific verifier (such as in SRP), I think I would need to add the verifier API into this array in Exlog_built_plugin_data.php:
array(
"section_name" => "Password Hashing",
"section_slug" => "password_hashing",
"section_description" => "These settings specify how the password has been hashed in the external database.",
"section_fields" => array(
array(
"field_name" => "Hash Type",
"field_description" => "
This is the hashing algorithm used.
Hashing should ALWAYS be used in production.
For help on knowing which algorithm was used when creating your external database password hashes check out the plugin <a target='_blank' href='https://ww.wp.xz.cn/plugins/external-login/#what%20hashes%20are%20available%20and%20which%20does%20my%20external%20database%20use%3F'>FAQ</a> section.
",
"field_slug" => "external_login_option_hash_algorithm",
"type" => "select",
"select_options" => array(
"bcrypt" => "bcrypt",
"phpass" => "phpass",
"phpcrypt" => "phpcrypt",
"md2" => "md2",
"md4" => "md4",
"md5" => "md5",
And then would I add the verifier API code into: validate_password.php ? Are there any other files I should worry about?
Also, do you feel I should bring up these questions in your Github issues rather than in this support forum?
You’re right about the default data. WordPress for example expects an e-mail address so if a user tries to update their user in the admin area they are forced to add one (even if the external system doesn’t support them).
There is definitely an issue where different user data is stored in different tables. The plugin doesn’t currently support this and I imagine this could be a hugely complex integration. There is a risk of creating an overly complicated UI when most users will have all user data in one table. I have been asked for this feature before but I just think if at that point users may be better coding their own solution. Criticism welcome on this thought.
I’ve never heard of SRP or other such systems but just had a quick read and it sounds cool. You would need to add the admin verifier to that options section. You’d then need to hide fields that weren’t relevant to that option.
I think the only files to modify would be:
- validate_password.php – to accommodate for your custom SRP system
- Exlog_built_plugin_data – to update the options required. If you need more field control or other field types other files may need updating. PELASE NOTE – I’ve just realised that options_fields.php is no longer used in the plugin and the deactivation hook is not working correctly because of this. Something to add to my backlog! It also looks like BuiltPluginData.php is a duplicate that needs removing.</li
- db.php – for all the querying
Welcome to bring them up issues either here or on Github.
I would love to work with you more closely with this but I just don’t have the time to work on a project of this size at the moment. I am however of course happy to answer questions and discuss options with you. Just want to be upfront about what I can realistically offer. I’m investing my time in learning automated testing for the plugin at the moment.
Thread Starter
kevent
(@kevent)
I think for specific issues or implementation questions, I would add them to your GitHub project. General questions or speculations, I can send them here in the WordPress Support.
A few comments:
1. Can you add some of the issues such as the options_fields.php is no longer used and deactivation hook is not working into your GitHub issues tracking? If I start to tackle using and integrating the project, and we come across some things we can fix in the process of adding/refining features of the plugin I would be happy to take a crack at some of the fixes. But you know these issues best. The issue added doesn’t even need to be that detailed at first. But when fixing, more questions could be asked.
2. The way I would handle the different user tables and still maintain your current simple to use UI and wp-config setup is that if a user inputs a blank table name, then the user fields name could contain maybe a comma delimited pair of “table name, field name” as the mapping input. So, only advanced users need to know this a feature. Otherwise, the UI works the same as before. It wouldn’t handle the case of different databases, but that would be pretty good already.
3. As stated in my other post, I’d start first with a PDO based re-write of db.php. It would be nice to get your thoughts on how you were going to re-write it. Maybe I would try to do it for the project.
