Bug in Magento affecting development sites using base_url

I installed a copy of Magento on a dev site I setup to do some testing with Varnish with (more on that later). However, in the requirement to be able to get to Magento using 2 different URL’s, I stumbled across this quite annoying bug.

a:5:{i:0;s:67:"Illegal scheme supplied, only alphanumeric characters are permitted";i:1;s:729:"#0 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/Store.php(712): Zend_Uri::factory('{{base_url}}')
#1 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(313): Mage_Core_Model_Store->isCurrentlySecure()
#2 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(161): Mage_Core_Controller_Varien_Front->_checkBaseUrl(Object(Mage_Core_Controller_Request_Http))
#3 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/App.php(349): Mage_Core_Controller_Varien_Front->dispatch()
#4 /home/dan/workspace/magento1610/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#5 /home/dan/workspace/magento1610/index.php(80): Mage::run('', 'store')
#6 {main}";s:3:"url";s:85:"/index.php/admin/system_config/edit/section/web/key/41c8c3d3f4bcb72e3c267ae0b73333d7/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

Bug reports on Magento’s site here, here, here and here. Not being patient enough for Varien to fix it, I developed a small extension which resolves the problem. It’s available to download below.

Put the tarball in the Magento webroot and extract. After you install this extension, you’ll need to empty the cache manually (if it was enabled). I assume if you’re reading this, then your Magento installation is broken. To do this, simply remove the contents of var/cache in Magento’s webroot.

When you re-visit your Magento’s front or backend, the problem should vanish.

[download id=”24″ format=”7″]

Updated 9th January 2012: It apparent that, attempting to login before applying this update with {{base_url}} set screws up the admin login cookies somehow. When you apply this patch, you’ll probably need to empty out your chosen browser’s cookie jar before attempting to login. You can tell if you need to or not by trying to login, and Magento coming back to you with a login screen, with no failed login message.

Updated 12th January 2012: Magento was released today. I can confirm that this problem still exists and has not yet been fixed (despite what the developers have written on one of the bug reports).

Updated 25th April 2012: I can confirm that this problem has been resolved in the latest version, released 24th April 2012.

Join the Conversation


  1. @Sky;
    It sounds to me like there’s still some caching going on. Are you using an opcode cacher like APC or similar? If you are, try flushing this out as well (simply restarting your favorite web server usually suffices). Make sure the contents of var/cache are completely emptied out, and your browser hasn’t cached anything either.
    Other than that, I don’t really know what else could be causing the issue. Though, if you’re still having problems after that, contact me directly with FTP and Magento admin details and I’ll see if I can help you out.

  2. This worked for me as well.

    Would you mind explaining at a high level what this issue is and how you go about solving it?

  3. Well, from what I can see, Magento has changed the method in which it detects whether the store is in SSL mode or not. This is something they’ve been messing with for a while. In v1.6 (I think) they introduced this “SSL_OFFLOADED” HTTP header which allows you to tell Magento it’s in SSL mode, even if the web server (Apache) believes it isn’t (for instance, if you offload SSL encryption to a load balancer, or front-end static-content web server like nginx). This has obviously changed the isCurrentlySecure() function inside the code in order to accommodate for this new feature (which I already have made use of on production sites, so it’s not all bad!). However, I can’t explain why they changed what they did and released with it breaking {{base_url}}. It’s a common thing to use this on development sites, and they know that developers do use it because they put that warning up saying “you really shouldn’t use {{base_url}} on production systems”.

    Basically, my fix overloads the function that does the detection, and if the secure base URL parameter is indeed {{base_url}}, to parse it out into an actual URL (comprised of HTTP_HOST, SERVER_PORT, etc) before passing it into Zend_Uri::factory(). The extra 3 lines I provided into this function simply calls another built-in Magento function which substitutes {{base_url}} into the real thing. This end result then gets passed into Zend_Uri::factory() which then provides the relevant methods for Magento to reliably detect whether it’s in secure mode or not.

    Zend_Uri fails because it’s illegal to have { and } characters in the URL string at the domain level, which is where the exception that we’re seeing is thrown from.

    What’s more interesting is that Magento have yet to officially respond with a fix for this yet. They’re normally quite slow at that sort of thing anyway, but it makes me wonder if they’ve done this on purpose and they don’t intend to fix it. I guess only the release of,, or (whichever comes first) will tell us!

  4. Worked well, but now I can’t login to the admin backend anymore. I see even reset my pasword in the database, but it doesn’t let me in… any clues? does it have to do anything with this fix?
    thanks for your help.

  5. Hi Dan!
    Thanks for the fix – it worked!
    And thanks for the explanations!

    @ Diana: I have the same problem, tried the same to solve it; so far without success.
    Have you tried the reset-password option?
    In my case, it resulted in a blanc email; I reckon some misconfiguration of the testshop i’m currently working on.

  6. @Johannes, @Diana

    I highly doubt this extension is causing admin login issues. All this does is replace {{base_url}} with the correct URL so that Magento can reliably detect if it’s running in secure mode or not. The code I provided does nothing of the nature surrounding admin login, and I also strongly suspect a configuration issue with the store itself.

    However, without any more to go on (error logs, access to be able to diagnose myself) I can’t really offer any more information/help. If you want to use the contact form and give me URL’s to the test store, admin login credentials to try to use, and access to the codebase (FTP, etc), I can try and see why you’re having issues.


  7. @Dan,

    I apprechiate your reply and helpfulness very much!

    You could very well be right – in that case of cause, I deeply apologize!

    Here’s some more details; some more via the contact form.

    It’s not really causing errors which one could see, but simply leads one back to the login page after sending the data. No JS error, no errors anymore in var/report/ – that was fixed by your code πŸ˜‰

    I compared the HTML source of the login pages of both productive and testshop – no differences apart from paths and (of cause) different form_key values.

    Again: frontend is ok! πŸ™‚ thanks again!

  8. Hello Dan & all,

    no more login-problems: after clearing all browser sessions and the corresponding cookies, the problems to login to the backend vanished.

    So thanks to Dan again!


  9. Worked well, but now I can’t login to the admin backend anymore using chrome. If i use mozilla firefox it works fine.

  10. Hi Dan,

    im running Mamp with a clean install and the fix isn’t working,

    i copied the files, restarted my webserver but a no go for me

    http://localhost:80/store/ out shoot i reinstall with the disable url fix check on



  11. Thank you very much, the extension works like a charm.

    I had problems logging into the backend as well, but cleared cache and sessions after which it worked perfectly.

    (Running MAMP 2.0.5 and Magento

Leave a comment

Your email address will not be published. Required fields are marked *