Title: HyperDB Compatibility Question
Last modified: April 2, 2019

---

# HyperDB Compatibility Question

 *  [kevent](https://wordpress.org/support/users/kevent/)
 * (@kevent)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/)
 * I have a question about the External-Login plugin compatibility for HyperDB or
   similar plugins that extend the wpdb class.
 * In the read me, it says:
 * > The plugin will re-create users in the WordPress database which has has two
   > benefits:
   >  1. It will allow you to use WordPress correctly with other plugins
   > that require a named user to be logged in. 2. If the ‘external database’ is
   > not available, you can allow the plugin to log them in with the local WordPress
   > version of their user.
 * Will the “local” WordPress database be accessed entirely through the wpdb class
   and work correctly with HyperDB type extensions that extend the wpdb class?

Viewing 4 replies - 1 through 4 (of 4 total)

 *  Plugin Author [tbenyon](https://wordpress.org/support/users/tbenyon/)
 * (@tbenyon)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/#post-11383646)
 * 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](https://wordpress.org/support/topic/external-database-connection-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](https://wordpress.org/support/users/kevent/)
 * (@kevent)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/#post-11385252)
 * 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://wordpress.org/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?
 *  Plugin Author [tbenyon](https://wordpress.org/support/users/tbenyon/)
 * (@tbenyon)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/#post-11388592)
 * 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](https://wordpress.org/support/users/kevent/)
 * (@kevent)
 * [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/#post-11389581)
 * 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.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘HyperDB Compatibility Question’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/external-login_fbebd6.svg)
 * [External Login](https://wordpress.org/plugins/external-login/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/external-login/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/external-login/)
 * [Active Topics](https://wordpress.org/support/plugin/external-login/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/external-login/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/external-login/reviews/)

 * 4 replies
 * 2 participants
 * Last reply from: [kevent](https://wordpress.org/support/users/kevent/)
 * Last activity: [7 years, 1 month ago](https://wordpress.org/support/topic/hyperdb-compatibility-question/#post-11389581)
 * Status: not resolved