saintandrews

Same problem, and not related to spaces. Just unrecognized.

Thanks! I’ll see what I can make of that.

In the meantime, if anyone else happens upon this thread, despite its humble GUI this plugin

https://www.ads-software.com/plugins/batchmove/

proved a fast, efficient and powerful after the fact route to cleaning out 3,000+ superfluous categorizations.

Yes, this sounds exactly like the problem I was having here, which I thought I had resolved by deactivating and reactivating the plugin but which just recurred this evening with a new post. New posts are directly readable via feed, but not visible on the home page.

Thanks. I thought I had; now it is.

Problem resolved.

@wpsolutions

That’s it. Forgot all about that setting, although the number of zombies being tagged on the first attempt today should have tipped me off.

My user appears to have entered their name correctly and claimed they were locked out on the first attempt, although they may have actually made multiple attempts. All my prior tests involved corruptions of my user name, which would naturally trigger the lockout.

When I unchecked the option and retested, the plugin worked flawlessly. Sorry for the false alarm.

To repay for the time I consumed here, perhaps a small intermediate refinement for sites with multiple users:

– Unknown/wrong username + wrong password – lockout on first failure (zombie killer)

– Unknown/wrong username + correct password – lockout on set number of failures

– Correct username + wrong password – lockout on set number of failures

Again, sorry for the false alarm

Thanks for responding, mbrsolutions. I’m assuming you’ve tested for this problem on all eight of your sites after the most recent AIOWPS update.

Following your suggestions, here’s what I did:

– Disabled my other security plugin and deliberately attempted to lock myself out of AIOWPS. I was locked out of AIOWPS immediately upon that initial attempt, not after the number of tries set in AIOWPS settings.

– Reenabled my other security plugin, disabled AIOWPS, installed a longtime, commonly used simple login lockdown plugin, and attempted to deliberately lock myself out. The simple login lockdown plugin performed according to its set parameters.

Conclusion: AIOWPS works well, largely as a convenience for me because I’ve already implemented a number of its features directly, except for this unforgiving first and only attempt behavior on logins, behavior which is only a bug insofar as it might irritate my resident blog users; I’m just as happy to have a zombie or hacker locked out on the first attempt. If the first time lockout behavior persists and becomes an irritant for my users, I can simply replace AIOWPS with the simpler plugin to address that core security function.

Thanks for responding, mbrsolutions. I have more than one security plugin installed, but I’ve had it prior to installing AIOWPS, it doesn’t replicate any of the features of AIOWPS, and this problem did not previously exist with both of them active. I’m not sure how many of the features of AIOWPS I’m using I’d characterize as advanced; probably not many.

Has this happened to you? Do you have a solution?

Yes, you’re right about the email notification; I’d forgotten that after I logged back in and gone to the Dashboard/Locked IP Addresses Page.

I sort of assumed that was your reason for blocking ranges; I seldom go to the trouble of blocking anything less than CIDRs in .htaccess myself.

If you were going to tweak this, why not at least supply the full octet IP address within AIOWPS as well, just as you do in email? That way, even if your default to block last octet ranges still proves a better practical solution for others/a majority, at least your WHOIS functionality within AIOWPS can immediately be used if desired. As it stands now, my options are a) IP address from email –> WHOIS bookmark in my browser –> IP address resolved; or the longer route b) IP address from email –> log in to (X number of) site(s) –> WHOIS function in AIOWPS –> IP address resolved.

Had this not been such a stellar plugin otherwise, I might not have noticed this.

The home page finally re-cached at 9:32 AM CDT, approximately 8 1/2 hours after the last known change to it. Still curious at that length of time.

This post is now moot. Since posting this I’ve deactivated the module in question and reconfigured Jetpack as well as clearing the cache to force a fresh start.

As the author of the post linked to above I should point out I have just updated it, and, in short, I have had and am having no problems with BLC.

However, BLC is more resource-intensive than other plugins I am running and it may be, if it is the case that the newer versions of WordPress themselves are also more resource-intensive than previous versions, that what is occurring is excessive competition among the parties involved for limited memory resources.

I should update this to stress that just a few days after I deactivated Broken Link Checker – again, after I had reset my autosave interval to 10 minutes, upon which the problem seemed to disappear – I reactivated BLC and have yet to have had any problems since.

My personal feeling remains that this problem may be related to an increased reliance on admin-ajax.php which at least one plugin author has previously noted, by having previously offered configuration alternatives to using it, can be resource intensive, and so it may be the case that it is the increased calls to admin-ajax.php which are spiking CPU memory usages beyond their allowed limits and in so doing severing the connection.

Sorry, Mika, I’ve been off the grid for a week and haven’t been online at all.

Just to be clear, I was saying that, first, since bumping my autosave interval immediately upon experiencing the problem myself (and perhaps having had a re-cache occur during that posting/problem process), I myself have not been able to reproduce the problem. I subsequently turned BLC off after ccolotti’s post simply as an added precaution since BLC is not a critical plugin.

The main thing I’ve noticed, again, is that my PHPIDS plugin has been registering REQUEST/POST.data.wp_autosave.content calls on /wp-admin/admin-ajax.php on every post and post edit continuously since 3.9, which it had never been doing previously.

I first noticed these alerts at the time I myself experienced the interminable saving problem. Since changing my autosave interval to 10 minutes, I myself have experienced no problem, multiple other authors have made multiple posts and have said nothing yet about having any difficulty (although I have yet to pointedly inquire), and PHPIDS keeps clicking off alerts on ajax.php. After having been gone a week, it’s up to 99 alerts or so.

This, to me, points to a rewiring of autosave and ajax in the new 3.9 as being implicated in the process, regardless of the actual autosave interval. Because I raised my interval to 10 minutes and thereafter haven’t yet reproduced the problem, I’m imagining it may be related to the specific autosave interval itself; the PHPIDS alerts are ultimately only a response to new code previously invisible or considered benign.

Finally, it could very well be my shared server. Every time I inquire of my dreamy host, however, server loads are nominal and everything is working perfectly; my host, therefore, will never be a problem I can actually address.

I’m confident WordPress will get around to fixing this. The autosave thing is not a new problem. It was a nuisance some time back, prompting a flurry of queries on how to raise the interval; I myself raised it back when to 120.

Plugins may indeed aggravate the problem, but they are not generating previously unseen code calls on ajax.php as detailed above: the root of the problem seems to lie there, at least from all the reliable information I have.

I recently installed Broken Link Checker through IWP and disabled it the connection problem went away….so it could be a plugin issue.

After increasing my autosave interval to 600 seconds, I also disabled Broken Link Checker per your comment simply as a precaution. Overnight, two users each made a post, and each post produced the same

REQUEST.data.wp_autosave.content

POST.data.wp_autosave.content

calls to /wp-admin/admin-ajax.php previously noted.

I don’t know what they experienced in the process of creating their posts, which were ultimately successful.

This leads me to conclude, first, that the BLC plugin is not the culprit, at least not on my site and, second, that the autosave line in my wp-config.php

define(‘AUTOSAVE_INTERVAL’, 600 );

is either no longer effective, incorrect, incorrectly placed, or now simply ignored by WordPress, at least with respect to producing this phenomenon.

As I previously mentioned, I myself have not been able to consistently duplicate the interminable “Connection lost. Saving…” problem with all plugins enabled, leaving me to question the value of laboriously testing with plugins randomly on/off; as mentioned, with BLC disabled the problem recurred.

I’m continuing to research this across the many information stovepipes available, and I’m seeing others with the same autosave-related experience with 3.9, some claiming to be related to plugins, some not.