Hyperknight

[Hyperknight]

Damn, what a shame. 🙁

If only I could find a way to stop Cloudflare from triggering it, I’d definitely keep it active. If you could find a way to whitelist IPs in a future update that would be fantastic.

Thanks again!

[Hyperknight]

Ok done!

Will disabling this option disable emails entirely or just stop the Cloudflare IP being recognised. Because I would like to keep the feature active (it’s useful) I just need genuine notifications rather than Cloudflare stuff.

Thank you!

[Hyperknight]

Then that solves my problem. I thought that changing the ‘wp-login.php’ will actually invalidate it from working in the string. I didn’t realise it remains interchangeable. If that’s the case, what is the purpose of actually changing the ‘wp-login.php’ section within HMWP?

Thank you for your help!

[Hyperknight]

This reply has been marked as private.

[Hyperknight]

This reply has been marked as private.

[Hyperknight]

Hey,

Yes, I’ve been through similar issues before. Unfortunately this time the WP-CONFIG file already had the wp-admin path name removed – and I’m not sure if it was its removal that was causing the 500 error or not, but it definitely wasn’t there.

Anyway, resetting via the database has worked out.

Many thanks!

[Hyperknight]

Ok don’t worry about it. After messing for too long, I eventually deleted the following tables from my database:

– hide_my_wp
– hide_my_wp_undo
– hmwp_ids_installed
– hmw_all_plugins
– external_updates-hide_my_wp

And that seems to have reset the settings and allowed the plugin to function. Now I just need to reconfigure it all.

[Hyperknight]

After googling that code I think I took it and implemented it from this page:

Resolving The WordPress Multisite Redirect Loop

Previously I had a redirect loop problem happening and I was trying to resolve it. I possibly tried the code and then forgot it was there.

Should I keep the “set_time_limit(90);” code then? I’m not sure what it does exactly.

[Hyperknight]

Well Suman, mind blown!

I started going through htaccess and then wpconfig details of the primary domain and subdomain, making comparisons of what was different. Since the subdomain is newer, and only has some security plugins, it was emptier.

I looked for elements that were in the primary files and not in the subdomain files, and sequentially tried deleting them or changing the code.

After going through the htaccess, I was right at the end of the wpcongig comparisons when I found this code:

set_time_limit(90);

define(‘COOKIE_DOMAIN’, ”);
define(‘COOKIEPATH’, ”);
define(‘SITECOOKIEPATH’, ”);

It was another element not present in the subdomain wpconfig, so I deleted it, and bam – the new admin name works, 404 eliminated!

I’ll leave this here for future reference for anyone with a similar problem, but I was hoping you could tell me what this code is, because I’m not sure if I added it, why I added it, or if a plugin added it, or what its function is!

Either way, with it gone the admin now works as it should. Very happy!

[Hyperknight]

This reply has been marked as private.

[Hyperknight]

I haven’t tried switching to the WP default theme, but I’m not sure it would help me if it suddenly worked as I need to use the theme I’m on now.

I have an alternate method for testing that I’m trying now. If I discover anything I will update here.

Appreciate your help!

EDIT: Ok! Just did a little test. I set up a subdomain under the primary site URL using WP and the same WP theme, but only a handful of plugins (but the same security plugins). I tried changing both the wp-login and wp-admin names and they both worked first time without a hitch.

This tells me that it’s not some external setting affecting the entire server, or else it would affect both the main domain and subdomain WP installs the same way. It must be something within the primary domain installation that’s causing the 404 login loop.

I’ll do my best to figure it out, but I’m unsure how to start, since I already attempted disabling all plugins and bringing them back one by one, and that didn’t help.

• This reply was modified 9 years ago by Hyperknight.
• This reply was modified 9 years ago by Hyperknight.

[Hyperknight]

Hi Suman,

For the record and for anyone else that may encounter a similar issue, I couldn’t get this resolved. In the end I’ve opted not to change the admin name via HMWP, but only change the login path, which works fine.

No other option unfortunately, I can’t figure it out!

[Hyperknight]

Suman I’m going to do a backup restore and start over, deleting the HMWP entries in the database as before.

When in the admin I can search the security plugins for potential conflicts, and if nothing works I will try to find an alternative to this feature or just have to leave it out. 🙁

[Hyperknight]

Hey Suman,

I did exactly that, deactivated all and restored them.

During the process I left HMWP until last. During the activations I was able to access the admin using the newly assigned admin name in the URL string “http://mysite.com/mynewadminname/index.php”, but every time a plugin was activated it sent me back to the login screen again. Then after logging in and returning to plugins page, I would find the plugin successfully activated. I have no idea why it was doing this.

Finally I activated HMWP last, and that’s the one that causes total lockout. Now trying to access the dashboard or plugins page is resulting in the same 404 error.

After login I’m now automatically getting directed to the site’s front end rather than the back, the same as before.

I really hope you have some ideas about this, I’d really like to get my site working again.

Thank you!

[Hyperknight]

Sumran, it looks like the folder you should have renamed was the plugins! After deactivating all plugins I can get into the admin with the new assigned name – but only if I add “/index.php” to the end. I’m not sure why this is.

I’ll reactivate each plugin one by one until I find the conflict.

[Author]

Posts