Howdy!
As detailed on the module support page, WPCC just lets you use your WordPress.com account to log into your self-hosted site.
Sorry to hear that it’s not authenticating properly, I’ve been able to duplicate the issue on your site. I’d love to have a chance to take a look at your site’s codebase, plugins, and the like to track down the issue — any chance you could email me a set of dashboard and FTP credentials?
georgestephanis at automattic.com
Thanks much!
I’m so exhausted I am just going to call it a night and will extend this tomorrow, but I have had two separate sites become completely inaccessible to registered users after putting WPCC on them, and then disabling it (because it didn’t work, caused people to go to text only error pages, and we were for the dyslexic customers and children hoping the Effing math problems would go away (My six year old does not know his multiplication tables through the nines yet.).
I’m heartbroken because when swapping out MD5 values for passwords, based on the assumption that our logins had been damaged didn’t work I tried to make the client happy by working 24 hours a day for two days making a whole new site, gratis. And the site lasted all afternoon, until I updated the FQDN in General, not to change where it points to but to remove the camel case in StockWatchIndex. I was immediately tossed out, and my other user I had open on my laptop had passed the new timeout that we ALSO didn’t ask for, and neither computer will let me log in again.
Let me assure you, I thought I was prepared for the little s%^& this time. Four admin accounts, LastPass loaded and tested so I can’t miss-type anything.
I’m hosed here. Well, trying to keep a sense of humor, I’m hosed here at http://www.StockWatchIndex.com. Something is playing a game. Is there a possible bug where we are being returned to the login page on successful login as well as failed?
Hey Kurt:
Just to make sure we’re clear, are you saying that activating WPCC will not let you log in traditionally with your username and password? There’s nothing in the codebase that should affect that — it’s merely an additional option.
Could you provide me the text from any error pages that you’ve got?
Getting logged out of your site when you update the URL is normal, and that’s part of WordPress core. The login cookies are signed by a COOKIEHASH that is a md5 of your siteurl. When the capitalization changes, the hash naturally changes as well.
That’s nothing to do with WPCC. Could you please clarify what your issue is?
There were never any error messages. No matter what we logged in as using the normal WordPress logins, we’d get the dialog box shake. And pushing the button to try and log in via WordPress online did give me an error at the top of the page, one line of text, but I have not written it down, and I am afraid I won’t be duplicating it if you know what I mean 🙂 I’m just happy to have managed through restoring backups and sheer dumb luck (it is an Amazon AWS instance and I had a very recent image of it to roll back to, right before installing Jetpack)gotten in and out of trouble. After all, some of us used to program for WordPress projects, but our business here is SaaS in a completely different area and we are just using WP sites to do promotional work. I’ve become my own annoying voice from the past – a customer who doesn’t take notes and just expects it to work!
I see where the cookie hash would be case sensitive being an MD5, and one of the first things I have done is toss all cookies anyway after giving their contents a once over. I’m on a Nginx server which has not had the RPC issues fixed yet. There is no way that is involved with shaking hands with the WordPress server is there? Because we would run straight into a brick wall if that was the case. (Strike that – the original server to have the problem was Apache at GoDaddy).
Oh well, I’ll let sleeping dogs lie. Appreciate your time though.
