3

I have the extension which is listening to core_layout_block_create_after event. It could be any event which is firing in magento admin. Also I have magento instance with compiler mode enabled. I installed the extension through magentoconnect. Installation was successful and cache was cleaned. Now, after returning back to admin I will get the error:

Mage registry key "_singleton/extension/observer" already exists
 /var/www/magento/trunk/app/Mage.php(222): Mage::throwException('Mage registry k...')
 /var/www/magento/trunk/app/Mage.php(476): Mage::register('_singleton/exte...', false)
 /var/www/magento/trunk/includes/src/__default.php(21023): Mage::getSingleton('extension...')
 /var/www/magento/trunk/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('core_layout_blo...', Ar
ray)
 /var/www/magento/trunk/includes/src/__default.php(27297): Mage::dispatchEvent('core_layout_blo...', A
rray)
 /var/www/magento/trunk/includes/src/__default.php(27310): Mage_Core_Model_Layout->createBlock('adminh
tml/page', 'root')
 /var/www/magento/trunk/includes/src/__default.php(27077): Mage_Core_Model_Layout->addBlock('adminhtml
/page', 'root')
 /var/www/magento/trunk/includes/src/__default.php(27043): Mage_Core_Model_Layout->_generateBlock(Obje
ct(Mage_Core_Model_Layout_Element), Object(Mage_Core_Model_Layout_Element))
 /var/www/magento-demo/trunk/includes/src/__default.php(13507): Mage_Core_Model_Layout->generateBlocks()
 /var/www/magento/trunk/includes/src/__default.php(13432): Mage_Core_Controller_Varien_Action->generat
eLayoutBlocks()
 /var/www/magento/trunk/includes/src/Mage_Adminhtml_Controller_Action.php(275): Mage_Core_Controller_Varien_Action->loadLayout(NULL, true, true)
 /var/www/magento/trunk/app/code/core/Mage/Compiler/controllers/Adminhtml/Compiler/ProcessController.
php(59): Mage_Adminhtml_Controller_Action->loadLayout()
 /var/www/magento/trunk/includes/src/__default.php(13582): Mage_Compiler_Adminhtml_Compiler_ProcessController->indexAction()
 /var/www/magento/trunk/includes/src/__default.php(17927): Mage_Core_Controller_Varien_Action->dispatch('index')
 /var/www/magento/trunk/includes/src/__default.php(17484): Mage_Core_Controller_Varien_Router_Standar
d->match(Object(Mage_Core_Controller_Request_Http))
 /var/www/magento/trunk/includes/src/__default.php(20061): Mage_Core_Controller_Varien_Front->dispatch()
 /var/www/magento/trunk/app/Mage.php(683): Mage_Core_Model_App->run(Array)
 /var/www/magento/trunk/index.php(87): Mage::run('', 'store')
5

The only way that I think is possible to consistently avoid this is to turn off compilation mode before installing / making any code changes. You will also need to rerun the compilation process after the installation. Simply re-enabling it will have the same issue.

The underlying problem is that with compilation mode enabled Magento parses the new config.xml files but will only look for classes under the includes/ path. When you install a new extension the new files are placed in the standard Magento paths and are not found by Magento.

If the extension were to include the files in the compiled state as well as uncompiled state this could be an option to prevent this. The sql installation routines are also not part of the compiled state and could be used to change the php include paths (this seems rather hackish).

I consider this behaviour an oversight in the Magento compilation mode implementation - options that would have made sense are 1.) a change in config invalidates the compilaton mode 2.) config is also compiled to have a consistent site

| improve this answer | |
  • I might add that the error message is a result of a bug in Mage::getSingleton() method. You should see an other error not this one. The getSingleton() method checks if (!self::registry($registryKey)) but when there is a record for that specific key and it's false (or null or zero) you get an error. In this case (as @Fooman sais) your class is not found and false is registered. – Marius Jun 25 '13 at 13:10
  • I am looking on this situation as extension owner. And it would be nice to find a non hackish solution. But during investigation I've found nothing. – oleksii.svarychevskyi Jun 25 '13 at 13:15
  • What Fooman described is not a hackish solution. It's actually a feature. When installing a new extension the compilation must be redone. See this: support.sweettoothrewards.com/entries/… – Marius Jun 25 '13 at 13:21
  • @Marius the hackish comment was only relating to try to undo the compilation mode include paths in the sql installation routine files (in case the user of your extension forgets this important step from your installation instructions) – Kristof at Fooman Jun 25 '13 at 13:33
  • Oh...sorry. I misunderstood – Marius Jun 25 '13 at 13:36
4

You'll need to re-run the compiler via System > Tools > Compilation.

| improve this answer | |
1

I am sorry about answering so late but I want to describe how I fixed that bug. The problem was that my observer was attached in global area to core_layout_block_create_after event, which is firing in both areas (frontend, admin).

After installation during Compilation Mode enabled cache was cleaned. But code was not recompiling during installation. It means that after returning back I could not access admin, and rerun compilation. I could do that only from console.

As I needed watching for that event only for frontend area I just moved the observer initialization. And problem was fixed.

My advise do not initialize observers in global scope for events which runs in every page in admin.

| improve this answer | |
  • 1
    Your advice is not a good one. Its completely ok to register for such events. That you did not need it there was your case, but others could need it. The correct advice would be to recompile before activating the usage of the compiled code. – Flyingmana Feb 24 '14 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.