peterdog

The redirection has nothing to do with those fields, which is my bad – this redirection is solely associated with not filling in the correct auth code.

If you are using the old method, the redirection had nothing to do with a successful or not login – solely on the correct or incorrect login URL.

This is primarily targeted at bots and I’m taking steps to make a comprehensive security plugin one feature at a time – then it will all come together based on what’s working and not.

Does that clear it up?

Let me see if I can work it into a 4.1.0 in the next 2 weeks for you and those who will miss it. I can assure you that it will be a major pain in the butt if you spend any time in the dashboard.

WP 3.6+ (if you are on a bleeding edge version on any dev site, they’ve already pushed out 3.7-alpha due for release in October and 3.8 in December) has the Heartbeat API, which brings up a pop-up login form when you’ve had session inactivity. When that pops up, that form is pulled from wp-login.php, which is a redirect, so bye-bye from whatever you were just working on. Time to go back to your hidden login, log back in, and navigate back to where you were.

It personally drove me nuts for 2 months knowing it was coming for everyone using the plugin (see download stats to see my anxiety).

http://wpmu.org/wordpress-3-6-the-new-heartbeat-api/

I did find a way to disable the Heartbeat API and forwarding of addresses like /login and /dashboard and /admin to various locations in the install, so perhaps those as options, also, would make for a comprehensive settings page.

I’ve got 4 or 5 full-site projects backed up and a deadline on one today and another next Friday, so it’ll be at least 10 days. A few hefty contributions will aid in sitting down and re-coding those options. This was the result of 2 months of thinking and researching, 5 hours of re-coding the entire plugin for efficiency, and 5 hours of squashing the backward-compatibility issue for people who haven’t been to the Settings page yet.

Because 90+% of the tickets on here have to do with some other plugin or some other feature like password-protected pages not knowing what to do with a login page that is no longer there. The primary function was to kill bot attacks and now that I have done this, I will have the option in v5 to give people the option.

Let’s see which one works best for the masses and then let people choose.

If you clear out that field, you will get your old settings back. You may want to use the variables in the wp-config.php method, though, so you can control your question, answer, and redirect there. (because it’s backwards compatible – and the notes said you didn’t have to change methods)

4.0.0 is out today. It still uses the wp-config.php option because I had a typo that I had found out how when that statement is missing a “not” in there.

The trick is that IF this is multisite, then the menu item is one place, else another.

I do have a function for MS:
if (function_exists('is_multisite') && is_multisite()) {
so I could put the menu functions there, but I’d have to test it on a number of configurations before I release that.

Thanks for writing. No, there’s no way to bookmark it.

I’ll have to look at how to obfuscate the text like the WP password, yes. Good idea. I’m already working on an md5 hash, but this just needed to be released with WP 3.6 coming down any day now.

v4.0.0 is coming out today if I can sort out backward-compatibility. It works flawlessly on new plugin installs but stealth breaks if people don’t re-visit the settings page.

Thanks – I love frustrating roaches. It’s so satisfying.

Correct. Thank you for pointing that out. I’ll resolve it in the version coming out this week.