PHP Fatal error: Uncaught exception 'Mage_Core_Exception' with message 'Mage registry key "_singleton/core/session" already exists'
You’ll see this if you try and do
Mage::getSingleton('core/session')
from a command-line magento script which hasn’t had the session initialised already. A simple workaround is to load the session model yourself early in your script:
$session = Mage::getModel('core/session');
Magento has lots of great thirdparty extensions available, but one annoyance is that they tend to make your configuration page look pretty messy. Each vendor tends to set up a new section in the configuration, which leads to a huge set of tabs.
To tidy this up, we can just make a small modification to the system.xml file for each extension, to force them all to keep their configuration together.
Here’s the system.xml from an extension as distributed:
<?xml version=”1.0″?>
<config>
<tabs>
<mageworld translate=”label”>
<label>Mage World</label>
<sort_order>100</sort_order>
</mageworld>
</tabs>
<sections>
<easybanner translate=”label” module=”easybanner”>
<label>Easy Banner</label>
<tab>mageworld</tab>
…
And here’s the change:
<?xml version=”1.0″?>
<config>
<tabs>
<thirdparty translate=”label”>
<label>Third Party</label>
<sort_order>303</sort_order>
</thirdparty>
</tabs>
<sections>
<easybanner translate=”label” module=”easybanner”>
<label>Mage World – Easy Banner</label>
<tab>thirdparty</tab>
…
The result:
After much discussion on freenode ##php about the issue, I’ve written up a howto for storing database passwords securely and safely.
So if you insert data into a mysql field that’s too long for the field size, the database will silently truncate the data being inserted. This is problematic!
To force mysql to fail these inserts,
set sql_mode = 'STRICT_ALL_TABLES';
In Magento, most extensions that actually do something visible need a .xml layout file. In 1.3 those files were usually distributed in app/design/default/default/layout – but in 1.5, if you have a custom design, those files won’t be used. According to this post the best place to put layout files for an extension is in app/design/base/default/layout – this means that even if you have your site’s custom theme at app/design/sitename/default, the extensions will still work.
However, most of the ’1.5-compatible’ extensions we’ve looked at still put layout files in default/default. This means that you have to copy the extension’s layout, templates, and skin files into your custom theme, even if you don’t want to change any of them.
Here’s an example from a purchased extension:
/app
/app/design
/app/design/frontend
/app/design/frontend/default
/app/design/frontend/default/default
/app/design/frontend/default/default/template
/app/design/frontend/default/default/template/Extension
/app/design/frontend/default/default/template/Extension/catalog_products.phtml
/app/design/frontend/default/default/template/Extension/catalog_categories.phtml
/app/design/frontend/default/default/template/Extension/pages.phtml
/app/design/frontend/default/default/template/Extension/links.phtml
/app/design/frontend/default/default/template/Extension/container.phtml
/app/design/frontend/default/default/template/Extension/store_switcher.phtml
/app/design/frontend/default/default/layout
/app/design/frontend/default/default/layout/Extension.xml
/app/code
/app/code/local
/app/code/local/Company
/app/code/local/Company/Extension
/app/code/local/Company/Extension/Helper
/app/code/local/Company/Extension/Helper/Data.php
/app/code/local/Company/Extension/sql
/app/code/local/Company/Extension/Model
/app/code/local/Company/Extension/Model/Extension.php
/app/code/local/Company/Extension/Model/Mysql4
/app/code/local/Company/Extension/Model/Mysql4/Sitemap
/app/code/local/Company/Extension/Model/Mysql4/Sitemap/Collection.php
/app/code/local/Company/Extension/Model/Observer.php
/app/code/local/Company/Extension/controllers
/app/code/local/Company/Extension/controllers/IndexController.php
/app/code/local/Company/Extension/Block
/app/code/local/Company/Extension/Block/Pages.php
/app/code/local/Company/Extension/etc
/app/code/local/Company/Extension/etc/system.xml
/app/code/local/Company/Extension/etc/config.xml
/app/etc
/app/etc/modules
/app/etc/modules/Company_Extension.xml
/skin
/skin/frontend
/skin/frontend/default
/skin/frontend/default/default
/skin/frontend/default/default/css
/skin/frontend/default/default/css/Extension.css
What we’re doing to make this work is
mv skin/frontend/default skin/frontend/base
mv app/design/frontend/default app/design/frontend/base
The result of this will be that even when we have a custom theme, this extension’s layout files will be applied without having to copy them to the theme-specific package.
So, new computer means setting up the development environment again. Here’s what I’m setting up today:
Netbeans PHP – as an alternative to trusty old JEdit
jdk
jruby 64 bit (32 bit ruby doesn’t work with vagrant)
virtualbox
a Debian VM
a debian .box file presetup for vagrant
vagrant – for provisioning VMs and handling host networking nicely
7zip
The plan: get xdebug going sensibly in a local environment.
An archive of my old 40k lists – surprising how many are just sitting on the server there…
Don’t access the magento session object while you’re hooking the controller_front_init_before event, as it’ll be set up incorrectly and give you a cookie error. You probably wanted to hook a pre or post dispatch event instead.
The script mentioned previously is here:
http://www.xi.co.nz/static/magento-configurable-check.phps
It’ll tell you whether your configurable attributes are set sensibly based on how many values there are. Note it assumes size and color as attributes you care about – you can change that on line 38 if you want.
So I was writing a script to check the integrity of configurable products on a couple of sites – it appeared that the attributes on some products didn’t match the actual set of child products available, so you had weird results like dropdowns with 1 color available.
It worked okay on a site with 250 active configurable products, but ran out of memory quickly on a site with 1000. What was going on?
It turns out that this line:
$attributes = $product->getTypeInstance()->getConfigurableAttributesAsArray($product);
consumed 0.5-2MB of memory for each product – what’s happening is that the Configurable type singleton is storing the configurable attribute data on the $product that we pass into that method, in order to reuse it later. If we’re not planning on doing anything else with that product (eg it’s from a collection we’re looping through), this is just wasted.
To remove all the stuff the above method adds to the product,
$product->setData('_cache_instance_used_product_attribute_ids', false);
$product->setData('_cache_instance_used_product_attributes', false);
$product->setData('_cache_instance_used_attributes', false);
$product->setData('_cache_instance_configurable_attributes', false);
$product->setData('_cache_instance_product_ids', false);
$product->setData('_cache_instance_products', false);
worked.