BobSD99

Strange, I must have somehow interfered with the mechanics of the hook.

Nope, @taslimbd, no luck. Bizarre….

Sounds like WangGuard might be dead? From their site:

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

I paid (with a great effort) another month of one of the servers. In October 20th, I won’t be able to pay the bigger server. I’m making this effort, trusting the success of the Indiegogo campaign. Soon, I will post the campaign link and I hope that all users of WangGuard make a donation no matter how small it is. In other case, I will be forced to close down WangGuard definitely.

Thanks so much to everyone for your support, please spread the word about #SaveWangGuard…

An effective alternative would be to require the user to select a username as part of the registration process via this plugin. If this method existed, however, the ability to register via the login page would STILL need to be locked down.

Forgive me if a solution is already a setting, and obvious, but I did not see that setting or method in the documentation.

I have the same issue. Maybe some essential hook missing from this theme? Going to climb under the hood and see if I can spot what’s missing, but that’s probably a long shot. If anyone has any insight or advice on tweaking the update box to conform to this standard, that would be great.

Your plug-in is tight. With closer analysis I realized the issue was related to W3 Total Cache running on the network installation. I haven’t had time to track down which of the different systems in that plugin is causing the issues, but as soon as I disabled it your plugin was tweeting with blazing speed. Thanks and high praise for the great plugin!

I did notice that Yoast seems to exacerbate the problem, so that may be a clue. Your advice sounds good for shedding some light on what mechanism may be involved.

My set-up uses the JobRoller custom post, which publishes the content in a slightly atypical manner. After the final approval screen, it gives you a confirmation/receipt page. It is during this screen that the Apache processes start flooding the top read-out, and physical memory is quickly consumed. Lingering on this page, I’ve watched the CPU load go as high as the 80’s! However, if I quickly hit “OK” on this page, WordPress returns to the user’s dashboard, and the spawning of Apache processes still spike up, but are limited to maybe a half dozen, and the CPU load tops out at about 4-8 then falls back to normal levels.

The installation is also a Network install, so another layer of complexity in tracking it down. I’ll try your suggestions, and see if the apache processes runaway on standard wordpress posts in that site, and others on the network.

I had that, and updated the plugin to 2.6.9. The problem resolved.

The next release of W3TC, or WP? Most awesome plugin, by the way, Frederick. :o)

I’m concerned that this solution breaks functionality of at last part of this plugin. Does anyone have input there? Also, is this occurrence due to an isolated feature within W3TC, such that disabling that feature would eliminate this problem? Or is that what we’ve just done, by adding the recommended function? (thanks for the tweak, by the way!)