... there are even 3 of those and at least in 1.8 $CONFIG->www_root is populated with the URL from the session object whereas $CONFIG->wwwroot is populated from the URL stored with the site ... :-) which might be different in your case ...

I'll experiment with the given suggestions, although i think the 3 $CONFIG values should be streamlined. 

Ok, i ended up with the following code, but it feels a bit hacky and not elggy.

in my start.php i first do a call to the function that does the magic, just before the theme_init call. i first did the check_view inside the theme_init, but that doesn't work.

my question is now: is there any point in the event system that my check_view should be in? 

start.php:

check_view();
elgg_register_event_handler('init', 'system', 'theme_init'); 

function check_view() {
  global $CONFIG;

  $domainpart = $_SERVER['HTTP_HOST'];
  $CONFIG->wwwroot = "http://" . $domainpart ."/";  
  $parsedUrl = parse_url($CONFIG->wwwroot);
  $host = explode('.', $parsedUrl['host']);  

  $subdomain = $host[0];

  if (in_array($subdomain, array('iframe','mobile','m'))) {
    elgg_set_viewtype($subdomain);
    elgg_register_viewtype_fallback('default')    
  }
}

...

This is a known issue: http://trac.elgg.org/ticket/3688 and http://trac.elgg.org/ticket/3684

The site shouldn't crash, but this comes down to establishing best practices. What's the reason for calling elgg_view() in pagesetup?

I'm using it to 'extend' a menu item with a panel:

$link = elgg_view('core/account/login_dropdown');
elgg_register_menu_item(
'topbar',
array( 'name' => 'login',
'href' => false,
'text' => 'login' . $link,
'priority' => 450,
'section' => 'alt', ));

If i put the pagesetup before the trigger then everything seems to be ok, but i don't know if that has any side-effects?