OS1

Clearing all Cookies seems to have gotten the page back but there’s still some odd behaviour. For example our local server version always goes to the Internet version of the page which Indicates that WordPress SEO has written some kind of re-direction into the database but is maybe incapable of reversing it. Also, why is it dependent on Cookies for re-direction?

Has anyone found a solution to this? It seems very bizarre but the widget() routine gets called AFTER the page had rendered in the browser. This seems to happen as a matter of course for widgets that work. widget() is called while the HTML is being returned to the browser and then once afterwards! For these widgets that don’t work there is one call made to widget() and it is after the page content has already been sent to the browser. Why do some widgets work and some not when, on the surface, there is no difference in the code structure?! Is this a WP bug and has it been reported?

I was wrong, it’s not calls to wp_redirect that cause the site to get re-entered it’s the line “RewriteRule . /index.php [L]” in .htaccess. I don’t know if it the server setup that causes the global variables to get cleared in this scenario but cleared they certainly are.

I even raised a ticket on this, Ticket #15344 <https://core.trac.www.ads-software.com/ticket/15344&gt;, but it got closed as invalid. I think the issue got lost in my attempts to explain it! The reviewer appeared to think I was reporting an issue in my code rather than WordPress. However, the tests I did using file writes, which I explain at the bottom just before it was closed, do seem to backup my initial observations that the path of execution is being sent right back to index.php, due to calls wp_redirect() and therefore data is being lost. The observations could easily be indicative of something completely different but they do stand.

Many thanks Rhys. This is a more elegant solution to mine, which basically is not really very elegant at all but at least allowed logins and, as tjmcd pointed, out access to the global $current_user!

Yes, I am. Just posted another thread on the forum but looking how long this issue has been around I don’t think it’s going to get sorted. In my case it appears that the global $current_user is being wiped. The genuine wp-login.php must be doing something extra to make the user login “stick” but the code is somewhat intractable! If I login using the wp-login form everything is fine, but things stop working if you use the API. It looks like the API is incomplete or an extra function call is required to make the login “stick”.