WordPress.org

1. Anonymous
   Unregistered
   Posted 1 year ago #

   Is this version supported under 2.6?

2. Anonymous
   Unregistered
   Posted 1 year ago #

   probably best to contact the author and ask him/her directly - michael@endlesspoetry.com

3. mvandemar
   Member
   Posted 1 year ago #

   It does indeed work under 2.6 and 2.6.1, I just have not updated the readme yet.

   Peace.

4. ljmac
   Member
   Posted 1 year ago #

   I have noticed that Login Lockdown never seems to block anybody under my WordPress installation (2.6). I have just discovered why in my error logs:

   [26-Sep-2008 22:35:07] WordPress database error Table 'wp_lockdowns' doesn't exist for query SELECT user_id FROM wp_lockdowns WHERE release_date > now() AND lockdown_IP LIKE '202.45.104%' made by islockeddown
   [26-Sep-2008 22:35:39] WordPress database error Table 'wp_lockdowns' doesn't exist for query SELECT lockdown_ID, floor((UNIX_TIMESTAMP(release_date)-UNIX_TIMESTAMP(now()))/60) AS minutes_left, lockdown_IP FROM wp_lockdowns WHERE release_date > now() made by listlockeddown

   Note that it is trying to block my IP, even though I have not made any failed login attempts. Also, Login Lockdown's mysql table was not created when I installed it (I tried uninstalling the plugin and reinstalling it, but the error is still there).

5. ljmac
   Member
   Posted 1 year ago #

   Actually, I believe I just found the solution to my problem here:

   http://wordpress.org/support/topic/181972?replies=9

   I just tried removing the hyphen from my login lockdown directory, and the database tables have been created! You really should fix your distribution so it creates a "loginlockdown" directory (not "login-lockdown" as it is now).

6. geeteegee
   Member
   Posted 4 months ago #

   After finding several similar problems with other WordPress plugins failing to create database tables and/or reporting redeclare errors trying to activate, lots of speculation and "have you tried this...", but no diagnosis and solution, I offer the following suggestions for Login Lockdown 1.3 on WordPress 2.7, but possibly of interest for other versions and other plugins as well.

   I found LoginLockdown was adding its option values to the wp_options table, but not creating its own tables. Apparently the add_action() for 'admin_menu' and 'login_form' were working, but add_action() for $activatestr was not.

   Since WordPress now deprecates the inclusion of wp-admin/upgrade-functions.php from wp-admin in favor of wp-admin/includes/upgrade.php, I changed both of the require_once() calls:

   82c81
   < 		require_once(ABSPATH . 'wp-admin/upgrade-functions.php');
   ---
   > 		require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
   99c98
   < 		require_once(ABSPATH . 'wp-admin/upgrade-functions.php');
   ---
   > 		require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

   My Debian multi-blog system includes ABSPATH at the front of PLUGINDIR, so the str_replace to create $activatestr was not working as intended. WP now recommends using register_activation_hook() instead of add_action($activatestr,...), so I replaced the PLUGINDIR dance with a register_activation call:

   270,274c272
   < 	if(!defined('PLUGINDIR')){
   < 		define('PLUGINDIR', 'wp-content/plugins');
   < 	}
   < 	$activatestr = str_replace(ABSPATH.PLUGINDIR."/", "activate_", __FILE__);
   < 	add_action($activatestr, 'loginLockdown_install');
   ---
   > 	register_activation_hook(__FILE__, 'loginLockdown_install');

   Now the activate call-back was working, but reported a Fatal Error attempting to redeclare loginLockdown_install(). One post suggested that the redeclare fatal error might really be a red herring, masking another error or warning that caused the problem. Another post suggested a workaround (not a fix) of surrounding the definition of the loginLockdown_install() function with:

   if ( !function_exists('loginLockdown_install') ) :
   <function definition here>
   endif;

   which just kicks the can down the road to the next function definition, so you have to move the

   endif;

   down to the end of defining ll_credit_link(), just before the //Actions and Filters comment. That revealed an error calling get_loginlockdownOptions() at the top of the file, before get_loginlockdownOptions() was defined the first time,

   66,67d65
   < $loginlockdown_db_version = "1.0";
   < $loginlockdownOptions = get_loginlockdownOptions();
   68a67
   > if (!function_exists('loginLockdown_install')) :

   so I moved the two executable statements below the function definitions and endif:

   265a273,276
   > endif;
   >
   > $loginlockdown_db_version = "1.0";
   > $loginlockdownOptions = get_loginlockdownOptions();

   That finally seems to have fixed the activation. Don't worry if your diff line numbers vary from mine, because I also added and deleted some debugging scaffolding and some optimization tweaks to speed things up in my local setup.

Topic Closed

This topic has been closed to new replies.