Fedora 16 to 17 upgrade

I finally had the opportunity to upgrade my laptop from Fedora 16 to 17. When I installed 16 originally, within the week 17 came out, and I was too busy to do anything about it. Granted now 18 is in beta, and is likely to be released tomorrow now that I’ve done this upgrade, I wanted to post about an issue that I came across that no one seems to have touched on much, or at least there’s no real mention of it online. Only by chance did using a couple of tricks combined sort the problem out.

Continue reading “Fedora 16 to 17 upgrade” »

Creating products programmatically in Magento

Let’s face it – importing is hard. Especially if it’s from some other unfamiliar product, or something that doesn’t already have a Dataflow/import plugin for Magento already. Dataflow has its limits. I’ve actually found it easier to import manually (creating models for products) as opposed to writing Dataflow routines. However, one of my biggest bug bears is not just creating products in Magento programmatically, but creating them successfully. We always end up with stock or relationship issues between simple and configurable products.

Continue reading “Creating products programmatically in Magento” »

Compaq CQ60 Display Issues – The Unexpected Part 3

I recently had an unexpected part 3 to this tale the other day, when the display went. Again. But this time, different symptoms. This time, the backlight went. Oh sh*t, replacing LCD panels isn’t exactly cheap, and since the backlight diffusers and CCFL’s are fused to the back of the LCD panel itself, there was no way of replacing the individual unit.

Continue reading “Compaq CQ60 Display Issues – The Unexpected Part 3” »

Get website-level configuration in Magento

I stumbled across this one a couple of times now, and it’s caught me out every time.

With Magento, you have the method Mage::getStoreConfig() to get a store-level config, but nothing obvious to get a website-level configuration (such as a default URL for the website).

So I used this;

Mage::app()->getWebsite($websiteId)->getConfig('web/unsecure/base_url')

It’s the same syntax as what’s used in Mage::getStoreConfig(), but uses getWebsite() instead of getStore(). Hopefully this won’t catch me out anymore!

Bug in Magento 1.6.1.0/1.6.2.0 affecting development sites using base_url

I installed a copy of Magento 1.6.1.0 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 1.6.2.0 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 1.7.0.0 version, released 24th April 2012.