I tried to disable a magento extension by setting it as "False" in /public_html/app/etc/modules/{extension folder} but now I am receiving an error
"Fatal error: Class 'Mage_Enquireproducts_Helper_Data' not found in /home/devbseatedglobal/public_html/app/Mage.php on line 546"
Why is this happening?
The extension probably has an XML file that has an attribute that looks something like this.
module="enquireproducts"
This XML instruction tells Magento to load the module's data helper to translate a string.
When Magento loads all those XML files, it places them into a cache so it only needs to load them once. Although you've disabled the extension, my guess is there's still a cached XML file somewhere. Try manually clearing your cache. (If you're running stock, cache files are stored in /var/cache/* -- you can clear them by deleting them)
It's also possible a different extension has XML configured that includes the attribute
module="enquireproducts"
If that's the case, these modules are dependent on that first module, and disabling that first module will basically break things unless you disable the dependent modules.
Hope that helps!
Related
I'm having an Issue with a blog extension in Magento CE 1.6.2.0.
I installed this extension: Neotheme_nBlog.
I created an entry in the administrator.
Then I went to http://www.example.com/index.php/blog/ to see the recently created entry.
What I saw was an error like this:
Fatal error: Call to a member function getName() on a non-object
in /home/example.com/public_html/app/design/frontend/default/caramel/template/magicat/left.phtml
I searched in google the terms: "template/magicat/left.phtml" getName and what I only found is sites having this issue, but no support at all.
Please note: I know what does that error mean in PHP ("unfortunately" I'm not new at that). What I don't understand is what's happening with such [NON/null] object and how to fix it without killing a dozen of kittens.
Question: What can I do to solve it? What is the nature of the error, regarding Magento?(again: not PHP).
Notes: The Magento site (http://magento.stackexchange.com) is somewhat poor and strict to bring support of such nature, so asking there is not an option.
Edit (as answer to comment, and to clarify):
Neotheme is still not responding the request.
Don't know what should I look on such file (instances are not initialized there, but only accessed).
I'm using the default theme (caramel), which has esthetical changes (does not have layout changes).
It's hard to say without seeing your system specifically, but on this
template/magicat/left.phtml
It looks like you've added a template named magicat/left.phtml to your system -- either via an extension or custom development. Somewhere in this file PHP's called getName on a non-object. There's a variety of reasons this could be happening, and without seeing the specific line of code PHP's complaining about in your system, it's hard to say. It'd also be helpful to know if magicat is part of the extension or something else.
The most common reason for this error in a template is code that relies on a block being there that's been removed by another extension (eitehr via layout XML or observer methods)
$this->getLayout()->getBlock('some_block')->getName();
The next most common is people using the registry to communicate between templates and views, but a registry key not being set
Mage::registry('some_item')->getName();
Without knowing the variable and context, it's doubtful anyone will be able to help you.
When using Dojo file caching with Worklight receiving a 404 Error when running in Simulator. It appears the file being loaded is not being copied from the common area to the device. Is there something else I need to define in my project to make that happen? There must be a convention and I wanted to follow it going forward as I expect to have more template files in the project.
My define statement in a .js file:
define(["dojo/_base/lang", "dijit/layout/ContentPane", "dojo/dom", "dojo/text!./templates/Order.html"], function(lang, ContentPane, dom, template){
...
var cp1 = new ContentPane({
title:"Order",
content: lang.replace(template, someJson)
}).placeAt("temp");
My folder structure:
In the common/js directory I have the above code in a .js file and I have a templates folder to keep the Order.html and I would expect to have other template files stored there in the future.
Error on the console:
GET http://localhost:10080/DojoProject/apps/services/preview/DojoApp/windowsphone8/1.0/default/layers/templates/Order.html 404 (Not Found)
It seems that the way you are specifying the path, browser tries to find the file in the "layers" folder which is sibling to "templates".
Have you tried to modify the "dojo/text!./templates/Order.html" to something like: "dojo/text!./../templates/Order.html" to navigate one level up, then go into the templates folder?
I'm not sure this will work, but I think it worths a try.
I'm struggling with an issue for which I can't find an explanation. I have two development environments that I use for my projects. I created a simple module for Magento and I tested it on one environment. After overcoming all Magento's complications, the module works as expected. This is on XAMPP.
I then copied the module to the development Linux environment, on a hosted server, and it crashes miserably. I did some debugging, and I found out that a call to Mage::getModel() returns bool(false) instead of the instance of the Model I requested.
I double checked all files and directories, and they match. Database is not involved (not from my side, at least, I don't need tables) and both environments have only me as a User, with Admin permissions.
Any suggestion on where should I start looking is welcome, thanks.
Added on 2012/07/09
Model contains a class named Diego_ClientCustomModule_Model_ExternalUserData, which is invoked with $model = Mage::getModel('clientcustommodule/externaluserdata');. Model file resides in Diego_ClientCustomModule\code\local\Diego\ClientCustomModule\Model\. The curious thing is:
If model file is named Externaluserdata.php, it works.
If model file is named ExternalUserData.php (i.e. it matches the class name), it doesn't work.
I'm aware of case sensitivity stuff etc, but, if the alias is all lower-case, how comes it can load a file having the first letter capitalized?
Configuration file
0.1.0
Diego_ClientCustomModule_Helper
Diego_ClientCustomModule_Model
Diego_ClientCustomModule_Block
standard
Diego_ClientCustomModule
ClientCustomModule
Snarking about the framework for which you are asking for help may not be the best strategy for receiving help.
Your issue is likely one of cache (remove var/cache folder to check) or one of improper casing. Note that the first letter of each directory and filename for files loaded by the autoloader (blocks, models, and helpers).
It seems I have found the root cause of the issue, although I can't figure out what kind of logic has been implemented to make it happen.
Model's file name was UserCustomModule.php, which reflected the class name UserCustomModule. That made sense, and worked wonderfully in XAMPP. Once I installed the same module on a Linux box, Magento silently ignored the file and, as previously stated, there's been no way to track down Magento's actions.
Following benmark suggestion, I went through all the files again to check the casing, and everything seemed to match. I then made something, in my opinion, completely stupid, and I renamed the Model file to Usercustommodule.php, leaving the class name untouched (after all, PHP should behave the same on both platforms, unlike the file system). Magically, the module now works! The file name looks cr*p, but it works.
This solved the problem, yet it raises more questions:
For what reason Magento has troubles loading a file with a CamelCase name? If it's Autoloading, it should simply find a file and load it. After all, it loads the Controller, the Block and everything else, and they are all in CamelCase.
Is it written anywhere that one or more files must have only the first letter capitalized? I got enough surprises already, I'd like to avoid new ones, if possible.
Thanks again for the help.
Magento seems to be using "Happy go Lucky" error handling, where all errors in xml files will just cause the xml config file to be ignored. And missing/wrong tags will just be ignored too, sometimes causing Magento to skip parts of the xml file.
But is there any way(A log file or something) which shows exactly what part of the config files Magento skips, and which tags are unknown/wrong. Using Magento 1.6 if that matters.
From what I have seen in Magento, it will throw out the entire XML file if there is invalid XML in it - broken/mismatched tags, erroneous characters, etc. I think it would be somewhat impossible for a xml parser to do any sort of a decent job parsing this out - that's the goal of XML. If my configuration isn't loading, the first think I like to do is go and perform a wellformedness validation on the code, which will show me if I have a problem there.
If there is references to invalid classes, usually it will break. Layout XML is different - it will ignore the block and continue on, which can be a real pain to troubleshoot.
So, to answer your question - no, there isn't a native way to do this. The best way, IMO, is to go and validate it at a third party.
There is logging in Magento, to enable it:
Go into your Admin Panel, then System > Configuration > Advanced > Developer
Under Log Settings ensure Enabled = Yes
This will create two separate logs in magento root/var/log (in my case /var/www/html/var/log)
Exception.log will hold any errors created using Mage::LogException($e)
System.log will hold any logging created using Mage::Log('message')
You can also create your own log files...if you so wish by
Mage::Log('message', null, 'my.log');
This will create a my.log file in the var/log directory.
FYI - I believe the reason Magento handles configuration files in this manner is to protect the rest of the system from an issue with a single extension.
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.
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.
Did you remove
AW_All.xml
AW_Productrelater.xml
from /app/etc directory
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 ...