Support » Plugins and Hacks » [Plugin: Login LockDown] Version 2.6 Support

Viewing 5 replies - 1 through 5 (of 5 total)
  • probably best to contact the author and ask him/her directly – michael@endlesspoetry.com

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

    Peace.

    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).

    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).

    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.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘[Plugin: Login LockDown] Version 2.6 Support’ is closed to new replies.