[Plugin: Active Directory Authentication Integration] Error: …Table 'DATABASENAME.wp_adauthin

Thanks for the report. I’ll see what I can do to get that fixed.

No problem. I took a brief look through the both versions (0.6 release and 0.7 devel) and it looks like it might be related to <b>class-active-directory-authentication-integration.php</b> in the plugin root.

The 0.7 version query that is causing the error seems to come from line 384:

if( 1 == $wpdb->get_var( $wpdb->prepare( "SELECT 1 res FROM " . $tablename . " LIMIT 1" ) ) ) {

In the 0.6 version, the corresponding code from line 372 is:

if( $wpdb->get_var( "SHOW TABLES LIKE '" . $tablename . "'" ) != $tablename ) {

Maybe that narrows it down a bit.

Yeah, that’s the bit that’s causing that issue. In the original release of the plugin, I was basically just trying to branch another plugin (Active Directory Integration), which (at least at the time) used a separate table in the database to store failed logins.

Since then, I’ve moved the failed logins out of that table and into one of WordPress’ standard tables, so in this version of the plugin, I’m trying to test for the existence of that table and remove it if it exists.

I’m committing an update right now that might fix that issue (it adds an option to the database after it checks to see if that table still exists, so it shouldn’t ever check again). Unfortunately, I won’t be in a spot where I can check to make sure I didn’t break anything else in making that fix until tomorrow. If you want to try it out, please let me know. Otherwise, I’ll try to report back tomorrow. Thanks.

Sure, I can can give it a go.

Version 0.6 does a similar check / cleanup though too, right? Why the change in tactics? Database portability I assume…

You’re right. I forgot that I started trying to delete that table in 0.6. I think I changed the way it tests for that table because I was getting lots of errors when testing the 0.6 way. After the change, I haven’t noticed as many errors about that particular item; but now (if this fix works), we shouldn’t notice them more than once.

The change in tactics as far as the data storage goes is simply because I have a personal dislike for plugins that create new tables instead of using the existing tables.

I totally understand the disdain for new (non WP) tables. What I couldn’t figure out was the change in the test for the table. “Lots of errors” is certainly a good reason to try a new test. ??

Hi all – I think this is related – I’ve got 3.3.1 & .06 — my php logs are filling up with –>

ok – I can’t seem to post my error message . . . the page keeps timing out

basically it’s a SQL error that says I cannot drop the table wp_adauthint because it does not exist . . . Is there an update?

@tunamaxx – I think I found the reason behind the decreased performance between 0.6 and 0.7, and I don’t think it has much to do with checking for the existence of the table.

In the current dev version, I’ve implemented a test to make sure WP can connect to AD before adding a filter to filter out login attempts. Unfortunately, the way it’s currently implemented, that means that WP is attempting to connect to AD every single time a page is loaded.

The logic behind the test was to avoid a situation where, when AD is unavailable, no one can login (even native WordPress users). I’m going to have to find a better fix for the issue, though, as the current dev implementation is most likely causing major performance issues.

@bloofrog – For the time being, you can safely edit active-directory-authentication-integration/class-active-directory-authentication-integration.php, look for the following code block, and delete it. Any future updates that would overwrite that change will fix the issue anyway, so you don’t have to worry about losing those changes in the future.

$tablename = $this->get_table_name();

			if( $wpdb->get_var( "SHOW TABLES LIKE '" . $tablename . "'" ) != $tablename ) {
				/**
				 * This table is no longer used as of version 0.6, so we should remove it
				 * 		if it exists.
				 */
				$wpdb->query( 'DROP TABLE IF EXISTS ' . $tablename );
			}

Beautiful – thank you so much for your response. I have removed this block and successfully removed the error messages.

@curtiss – thanks for the update. I had lumped the decreased performance in with the error log messages. Never occurred to me that they weren’t related.

Thanks for the update.