bodywise

The problem here are vague suggestions and recommendations. The migration to a new site is fraught with difficulties. How to access it given the fact it will have a new URL or domain name. This needs a careful and tight list of necessary steps. Explicitly stating that the new site needs a WP installation. With what database? How is that new database updated with the migrated set?

I have the same problem. My wordpress site crashes every time I try to activate Updraft. There is a problem not being corrected or updated. I use Niasrg theme. That should make no difference.

Thank you. I repeat, who beta tested this? 2 or 3 days beta testing would have been sufficient to tell you this is not ready for prime time.

And everyone should be warned. Turn off “automatic updating” for new WP versions.

• This reply was modified 6 years, 3 months ago by bodywise.

All the fanfare. WP 5.0 or 5.0.1 with Gutenberg is a disaster. Plugins developers are not catching up.

Totally agree. New upgrades should be greeted with enthusiasm. So often, they just make things worse. Who actually beta tested Gutenberg? Poor Johannes Gutenberg.

Totally agree. This new version is awful! This happens so often. You have a good product and someone decides it needs to be upgraded. But makes it worse. Bloated and awful.

So be honest this version is a nightmare. I uploaded a Word document into my “editor” and it has taken me a hour which should only take me a few minutes. Words are connected like thiswordisconnected. (runons).

Sentences missing. Title will not stick. You get an F on this one.

I wish we could downgrade. I will certainly not upgrade any other website.

I still believe this is a bug. You see so many people with the same complaint with scant solutions. It is possible that your solution modsecurity may solve the problem.

But why is this a variable problem? Seems to be a problem on some sites while not a problem on other sites.

I currently use Amazon web services where there is no cPanel. So the answer is buried in some hidden file. At a commandline level would you know where that is?

The fix appears to be /index.php/%year%/%monthnum%/%day%/%postname%/ It is the index.php that is key. But only the sites where the problem exists.

It is very simple. When enabling the name-based brute force routine, I am locked out. File not found. I am at a loss how this routine is enabled. It is not enable to the .htaccess file.

The cookie-based brute force routine also does not seem to be operative. But it does not prevent me from logging in. It simply leads me to the usual WP–login.php routine.

Repeating, every single time I use the name-based brute force routine I am locked out. The only way to recover is through the back door, deleting the entire plug-in. That allows me to login once again. I don’t know whether this is a permission-based problem. All my directories are CHMOD apache.

It has worked in the past when used InMotionHosting VPS server. But does not work with any Amazon web service instance.

Thank you so kindly for this response. It is a bug in the software. It does work on some sites. But the majority of my Amazon web services sites it fails uniformly. For this reason I haven’t given up on this plug-in. The rename login file when operative is bulletproof. I love this plug-in. Otherwise when it does not work it is not worth the effort. So have simply deleted the plug-in. It would be wonderful if we had an answer.

Virtually all queries and resolutions are relevant to the cookie-based brute force login and not the renaming brute force login. I have also found the cookie-based brute force does not work very well either.

Thank you very much again

It is not the htaccess that causes this problem. When you say you are having no problems, fine. It does not solve the problem we have. There is a bug in this program that is not being solved.

If you used the brute force rename login, it is a problem that plagues me without any answers from anyone. You need to sneak in the back door and disable the plugin. And you will be able to log in again. It is not the htaccess as is so often claimed unless you are using the cookie based oslution.

When it works it is bullet proof.

Quite frankly this is a bug that is not being recognized. It is universal and reproducible. It needs to be fixed without all these workarounds.

Unbelievable. It worked. I have only been struggling with this for a week. All the other fixes did not work. This fix worked. thank you! I still think this is a bug in WP that needs to be corrected.

So many people with the same problem. So few answers. All the answers on line do not solve the problem. So this must be a known bug in WP that no one is willing to admit.

It is maddening. You know the pages are there. They just don’t show up. I have tried all sorts of owner and permission settings. The usual htaccess rewrites. Nothing works.

Thank you but I find this question repeatedly asked without a true explanation.

I mentioned that I am using secret word not cookie. All your explanations are directed to cookie based.

I think the problem is related to WP in a subdirectory. What is the solution when locked out? All your soltiuons are simple fixes to repair the site not to solve the problem.

So … if WP is located in a subdirectory will the brute force secret word work? I think not. It does not affect the htaccess file. There is another solution. I think one other file needs to be changed. Which one? index.php?