User path is broken

Per catch, and blessed by Larry, moving this and all other WSCCI issues to the Drupal core queue.

Is this from #1329914: Ensure $_GET['q'] is set before calling drupal_normal_path()? That just got committed so a simple merge should take care of it. If not, please link to the core issue that it relates to.

/**
 * Set the active path, which determines which page is loaded.
 *
 * Note that this may not have the desired effect unless invoked very early
 * in the page load, such as during hook_boot, or unless you call
 * menu_execute_active_handler() to generate your page output.
 *
 * @param $path
 *   A Drupal path - not a path alias.
 */
function menu_set_active_item($path) {
  // Force a new context layer with overrided path. This temporary solution is
  // working, until we the menu system itself get refactored.
  $context = drupal_get_context();
  $newContext = $context->addLayer();
  $newContext->setValue('http:query:q', $path);
  $tracker = $newContext->lock();
  $tracker->disableTracking();
}

This fixes the issue temporarely until all other consistency issues are solved.
I added the Tracker::disableTracking() method locally on my development environment which allows to pragmatically force a tracker to be disabled so that kind of really low level procedural code can mess up with internals such as $_GET['q'] and ensure the menu system still work.

I know this is not really elegant, but it actually avoid the ugly user page WSOD and should avoid some others as well.

In preparation of core inclusion, this can be a totally legit workarround in order to have at least the base code being commited which would allow us then to proceed to deeper problems fix in more atomic issues.

That's a possibility. I have also been pondering an "unpoppable" context class that would never get popped for use super-early, at least until we can refactor the need for that out. The end result is effectively the same.

Thoughts, anyone else?

I'm ok with the super early context, but my guess is that some modules will probably attempt to override $_GET['q'] anyway, one way or another, I don't really see it being super useful in that particular case. For instance, when user_page() is being called, everything's already bootstrapped, active menu handler run etc... Context overrides may already have happened. My guess is that changing the menu router item being runed was an error from the beginning, we should find a nice solution for this kind of polymorphic menu entries that doesn't involve messing with the context. But this has to be done later once first WSCCI iteration is OK for core inclusion and done.

No longer relevant.