3

I installed a new module and now I get this error and can't log into the admin area of Magento:

Warning: include(Mage/Awautorelated/Helper/Data.php): failed to open stream: No such file or directory  in /var/www/spasandstuff.com/lib/Varien/Autoload.php on line 93

I have removed the module, cleared the cache and session folders and it still gives me that error.

I ran grep -r "Awautorelated" * and found nothing on the server. I restarted Apache to clear APC cache. Magento uses Lightspeed but I believe that just uses the Magento cache directory which I cleared. So I am at a loss as to how to fix this issue. Is there a database table that caches module info?

Any help will be greatly appreciated.

Drew Hunter
  • 10,136
  • 2
  • 40
  • 49
Chris Rosenau
  • 264
  • 1
  • 7
  • 19

3 Answers3

2

Somewhere, a piece of Magento code is attempting to instantiate a helper class with code that looks something like 

Mage::helper('awautorelated');
Mage::helper('awautorelated/data');

Since you've removed the module from the server and cleared your cache, there's no <model> node for the <awautorelated> group. That's why Magento is looking for this class in Mage/Awautorelated instead of AW/Awautorelated.

Based on everything you've said, my guess is you have an XML file somewhere, likely in the layout, that still contains an attribute something like this

<sometag ... module="awautorelated" ...>

These module attributes are used to specify a translation helper for "inner nodes". Your Magento system loads the XML file, parses it, sees the module="awautorelated", and then attempts to instantiate a awautorelated helper to translate the nodes. Since you've remove that module files, it can't instantiate the helper and yells at you. Try a case insensitive grep (or ack)

grep -i -r 'awautorelated'

and make sure you search the entire Magento source tree. Not just app/code, but app/design as well.

Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • Our database is on a different server. We restored the server to a good image and the issue was still happening. So Magento was caching the module in the database. We didn't track down where in the database as this was our live server. We proceeded to restore the database and that fixed it. I would still like to figure out which database table it happened in. – Chris Rosenau Jan 17 '12 at 22:40
  • @Chris Ah, apologies, I always forget that some magento objects allow you the specify layout XML updates. Top of my head that's going to be the table for cms pages, widgets, products, and somewhere in categories. I'd do a dump of the database and then manually search (via grep or a text editor) for the INSERT that's created. It should let you zero in on your specific problem easily. – Alana Storm Jan 17 '12 at 23:11
  • Also, I added a question asking for every place in a Magento system where this might happen. Worth watching (or adding to if you find the solution): http://stackoverflow.com/questions/8903052/which-magento-domain-objects-use-layout-xml-updates – Alana Storm Jan 17 '12 at 23:17
1

Did you remove

  • AW_All.xml
  • AW_Productrelater.xml

from /app/etc directory

Oğuz Çelikdemir
  • 4,990
  • 4
  • 30
  • 56
1

Yes, there is the table core_config_data, but I don't expect removing the module entry from their will be realted to this problem, but you can certainly remove the entry now the module has been removed.

Are you using memcached for caching? you could remove that. I'm not 100% sure restarting apache clears the APC cache either ...

rszemeti
  • 91
  • 2