Blind panic this week when our upgrade from 3.7 to 3.8 left our clients unable to log in. A bit fundamental that. This was on our major domain multisite implementation.
Which means we won’t be the only ones to be hit. Google is supposed to be your friend but all relevant search terms produced nought. Panic increases. Luckily I can still login as the network admin but what was happening and what do we say to our clients?
The first objective is to find a workaround. The network admin login was the clue here. If you try and login to the base domain as a user of one of the other multisites it accepts the login and whilst it denies access to the base Dashboard – it does offer a link into your own Dashboard. That bought some time while I scratched my head as to why this was happening to me and, apparently, to me alone.
It just did no make sense. wp-login would work for base but not for any subdomains and their associated domains. It did under 3.7. What had changed? The obvious culprit was the redirection. The .htaccess file had not changed, wp-config the same. Messing them about did nothing. I was in despair. Back to basics – why was the problem hitting us and no one else? What was different about our implementation?
It then clicked. Was I being screwed by my own cleverness? Earlier this year we were subject to a heavy and sustained attack on the WordPress login. Whilst brute force attacks didn’t get in – every attempt required a SQL lookup and with the rate of attack a heavy load on the system. It began to show on performance and we had to do something. The answer was so simple – have another login that avoided wp-login.php and make wp-login.php blank except for a terse bit of text saying ‘not here guv’. The attacks continued but as many bots don’t learn they were thumping an inconsequential bit of code with no appreciable system load. Performance returned to normal.
The next problem was WordPress updates are frequent and we have lots of WordPress accounts. I had written a script to automatically update and do the necessary global find & replace of the login and copy the code across to the new location. There was one problem. Our old implementations had WordPress in the root directory instead of its own WordPress directory. So the script bunged them in both just in case. It had worked flawlessly to date.
But 3.8 has a new bug/undocumented feature. It looks for wp-login.php (and its replacement) in the root directory before looking it the wordpress directory. And wp-login.php (and its replacement) will not work with the rest of the modules in another directory. It just hangs with a blank screen.
Simply removing the extra wp-login.php (and its replacement) from the root directory solved the problem. A bit of bad coding there WordPress. I wasted half a day on this on the last working day before Christmas so I have no time left to write up the bug. Sorry.
Meanwhile the good news despite the inevitable criticism of the look of the new dark Dashboard. OK style is one thing but functionality is rather more important. And what a joy the Dashboard is now responsive and usable on smartphones and tablets. I haven’t had a chance to test the new 2014 user theme but that’s responsive too. WordPress 3.8 is yet another milestone in the switch from traditional PC styled websites to fully flexible browsing.
So well done WordPress even if I was thinking the opposite four hours ago.
