Activated Centralized Site Management and now can't access admin
-
I clicked on the activate jetpack centralized site management banner at the top of the admin page and now get 500 internal server error. First I removed the jetpack plugin to no avail then moved out all plugins which still did not solve it. I’ve looked in error log and can’t find anything.
Is there anyone else having problems like this? I’m running a network install.
My site is here – any help would be greatly appreciated.
-
If you error logs don’t display anything, could you try to increase the memory allocated to PHP on your site, as it can sometimes cause blank screens as well?
https://codex.www.ads-software.com/Editing_wp-config.php#Increasing_memory_allocated_to_PHPIf that doesn’t help, could you ask your hosting provider to take a look at your logs? They might be able to find something about these 500 errors, or enabling more logging so we can find out more.
Let me know how it goes.
Haven’t heard back from my host, but I’ve been able to pick out some messages pertaining to the ‘validation of the security token’.
Also, I am finally able to access wp-admin in explorer, indicating that Chrome may be part of my problem – even after clearing the browser – cookies, files, images, etc…
Part of my success, I believe, is that I was finally able to completely remove the jetpack plugin – but now am confronted with a new release of WordPress.
I’m taking a backup at this point before I update to 4.1 and before attempting to reinstall JetPack.
Just to keep you up on the latest with this – I think progress is being made and hopefully can mark this resolved.
In the meantime,
Thanks for your support Jeremy!By the process of elimination, I believe I’ve found the guilty culprit. When I disabled the WordPress extension for Chrome and restart the browser, the problem disappeared.
Therefore, I’m about %99.99 sure that that was my problem. That would explain why other browsers didn’t share the problem.
I’ll mark this as resolved but I believe it should be looked into further and documented for future reference.
Thanks again Jeremy!
When I disabled the WordPress extension for Chrome and restart the browser, the problem disappeared.
That’s interesting. I also use Chrome and the WordPress extension, and have not run into any issues. My sites run WordPress 4.1 as well.
I don’t know if that matters, but could you let me know what OS you’re using? I’m on a Mac, but I could try to reproduce the issue on a Windows machine if needed.
I have the same problem. I just updated a few sites, and on the ones hosted at ipage, the Centralized Site Management activation causes me a 500 error.
On my sites hosted at bluehost, I do NOT have the same problem.
The sites that have not had the Centralized Site Management activated are all Ok.
I am using Chrome for all my access at the moment.
I can access my sites using IE, but when using Chrome I get the 500 error.
I looked for a WordPress extension for Chrome, as Steve D disabled his, but I don’t have one, so that doesn’t work for me.
@abcdiamond Could you check your server error logs, as I suggested above?
Jeremy,
I’m running Windows 7.
I had the problem re-surface in Chrome yesterday afternoon, though only briefly, after the WordPress extension was disabled. I noticed @abcdiamond mentioned iPage which is my host as well.
The problem seems to relate to the security keys, in my opinion, and by disconnecting JetPack from WordPress.com and then reconnecting, seems to help things. I have not clicked on the “activate centralized site management” again on any browser for fear of getting stuck again.
I’ve been running smoothly since yesterday afternoon.
Thanks again!
Jeremy. I have looked for error logs on ipage, but can’t find where they are. The access logs show nothing unusual, as far as I can see.
However, I just checked my sites again today (9am here) and they are now OK again. Maybe ipage updated something ??
I might actually try to use the “centralized site management” soon, as it is now activated on most of my sites.
I’m having the same problem on my chromebook; as soon as I clicked the opt-in button, I lost all ability to access my admin pages. Disabling jetpack didn’t help at all. The problem doesn’t afflict firefox, or even linux chrome, just my chromebook. Is there any way to opt-out once you’ve opted in?
ETA: One really weird addendum: If I try to log in in incognito mode, everything seems to work. Any ideas?
@steve D I tried to reproduce in Chrome and in IE 10 on a machine running Windows 7, but no luck.
What happens when you try in a different browser on your end?
Did you also get a reply from iPage about the 500 error logs?
I have looked for error logs on ipage, but can’t find where they are
@abcdiamond Could you get in touch with iPage and ask them to take a look? They might not give access to error logs to their customers.
@rraszews Your problem seems quite different from the other problems mentioned here. If you still experience issues, could you please try clearing out your cache?
https://en.support.wordpress.com/browser-issues/#clear-your-cache-and-cookiesIf that doesn’t help, you can opt in by clicking on “Configure” next to the JSON API module under Jetpack > Settings, and opt out there.
Jeremy,
Here are some common denominators:
- hosting – @abcdiamond and I are both using ipage
- client machine -I’m using an Acer Aspire One tablet – @rraszews mentioned he was on a Chomebook (basically the same thing)
- OS – Mine is running Windows 7 Starter and I suppose @rraszews may as well being a similar machine
- Chrome browser
I use CloudFlare, which I paused at the first sign of a problem and through the debug process. Also, my setup includes network install and BuddyPress, which may also add to the situation.
The ipage error logs can be found here – https://www.ipage.com/controlpanel/cgiManagement/cgiErrorLog.bml. The hosting support really wasn’t much of a help, they attempted to replicate the problem and couldn’t. The logs were convoluted with so many different messages, it was tough to find anything pertinent. The ticket with them is closed now.
I hope this helps some.
Thanks!
I’d tried rebooting and cleaning my cache, and it wasn’t any help, but when I logged in the next morning, the problem had gone away. I’m going to assume that either there’s some nuance to the caching that chrome does, or perhaps the problem actually originated with my web host. they have some aggressive cache settings that I don’t fully understand — I’ve had issues before with static html pages that produce 304 messages for a whole 24 hours after modification to some webkit-based browsers.
It sounds a lot to me like the common denominator is something being cached that shouldn’t be, but exactly why it’s so hard for some users to clear it out is a mystery to me. The fact that it seems to more often afflict browsers and devices that are optimized for mobile users certainly points to it being possibly related to aggressive caching.
With Cloudflare still deactivated, I clicked on the “activate site management” banner in a subsite causing the 500 internal server error – this was on Firefox. I went over to wordpress.com and disconnected the subsite from there, cleared the browser cache and restarted Firefox which seemed to resolve the server error. I then reconnected to wordpress.com, though not through the site management method, the old method of reconnecting and all seems fine now.
It’s probably noteworthy to mention that I had originally had jetpack network activated with some subsites not configured to allow remote in the JSON settings which may have invoked the “activate site management” banner, in turn, causing the server error.
At least now we can rule out Chrome as a common denominator.
Also, its possible that something cache wise expired at the time I disabled the Chrome extension so that could very well have been a conincidence.
I’m having this issue also, also with ipage after clicking the connect button tonight. Can’t access my admin panel at all, I can access my site, just not the admin panel.
- The topic ‘Activated Centralized Site Management and now can't access admin’ is closed to new replies.