I was looking for errors inside system.log file and I have seen thhis list of error that obviously is pretty useless since I don't understand where I have to look for inside the thousands files I have got:

2014-10-05T10:28:48+00:00 DEBUG (7): <config/>
2014-10-05T10:28:48+00:00 DEBUG (7): <config/>
2014-10-05T10:28:49+00:00 DEBUG (7): <config/>
2014-10-05T10:29:19+00:00 DEBUG (7): <config/>
2014-10-05T10:29:19+00:00 DEBUG (7): <config/>
2014-10-05T10:29:20+00:00 DEBUG (7): <config/>
2014-10-05T10:29:20+00:00 DEBUG (7): <config/>
2014-10-05T10:29:21+00:00 DEBUG (7): <config/>
2014-10-05T10:29:23+00:00 DEBUG (7): <config/>
2014-10-05T10:29:23+00:00 DEBUG (7): <config/>
2014-10-05T10:29:25+00:00 DEBUG (7): <config/>
2014-10-05T10:29:25+00:00 DEBUG (7): <config/>
2014-10-05T10:29:26+00:00 DEBUG (7): <config/>
2014-10-05T10:29:29+00:00 DEBUG (7): <config/>
2014-10-05T10:29:29+00:00 DEBUG (7): <config/>
2014-10-05T10:29:29+00:00 DEBUG (7): <theme />
2014-10-05T10:29:31+00:00 DEBUG (7): <?xml version="1.0"?><customgrid></customgrid>
2014-10-05T10:29:33+00:00 DEBUG (7): <?xml version="1.0"?><jstranslator></jstranslator>
2014-10-05T10:29:33+00:00 DEBUG (7): <?xml version="1.0"?><config></config>

These kind of errors appear both from frontend navigation(2014-10-05T10:29:23+00:00 DEBUG (7): <config/>) (every page) and backend navigation(both kind of errors).
So I'm wondering if there is a way to find the exact xml file that generates these reports.
I have seen this lines of code while surfing the web:

header("Content-Type: text/xml");
echo Mage::app()->getConfig()->getNode()->asXml();exit;

But I don't know in which files I have to put this sketch

These are the results for grep -r "<config></config>" * inside the app folder:

code/core/Mage/Admin/Model/Config.php:            $adminhtmlConfig->loadString('<?xml version="1.0"?><config></config>');
code/core/Mage/Install/Model/Config.php:        $this->loadString('<?xml version="1.0"?><config></config>');

These are the results for grep -r "<config/>" *:

code/core/Mage/Core/Model/Config.php:        $unsortedConfig->loadString('<config/>');
code/core/Mage/Core/Model/Config.php:            $mergeToObject->loadString('<config/>');
code/core/Mage/Adminhtml/Block/System/Config/Form/Fieldset.php:        return new Mage_Core_Model_Config_Element('<config/>');

This is the result for grep -r -w "<theme />" *

code/core/Mage/Core/Model/Design/Config.php:            $this->loadString('<theme />');

Isn't there a way to return the xml file with the problem?

  • Added log levels to answer. The message you're getting in the system-log are all level 7 debug messages. Note that they are Debug messages and not necessarily errors. From what you've found with grep, they're telling you about load events. It illustrates why normally, informational and debug messages are shut off in most system logging. – Fiasco Labs Oct 6 '14 at 15:28
  • @FiascoLabs is there a way to shut off informational and debug log without competely disable the log system? Is it global configuration or a specific module one? – Razorphyn Oct 6 '14 at 15:39
  • I'm looking into that, but you might try going into the System Config Developer Log settings. Change the Current Configuration Scope on the upper left to "Default Store View" and then clear the Use Website checkbox on Log Enabled. Leave the Log enabled. Change the Current Configuration Scope back to "Default Config" and set Enabled to No for logging. This will catch errors generated by the Store Front but stop a lot of unneeded logging. When you need full error logging, then you change the "Default Config" to yes and set the developer mode logging in index.php – Fiasco Labs Oct 6 '14 at 17:19
  • 1

Try using grep if you are running Magento on a Linux/Mac system.

I think it's finding empty nodes, the last three lines kind of indicates this. A developer may have inserted <config/> (self closed single entry) somewhere as a placeholder and never got back to fixing it.

Go to the current theme directory's layout folder and use the command:

grep "<config/>" *

and likewise for every other entry.

Just in case they're there for a reason, you can just comment them out with <!-- --> and test for function after the modification.

There are 8 levels of logged messages as follows:

const EMERG   = 0;  // Emergency: system is unusable
const ALERT   = 1;  // Alert: action must be taken immediately
const CRIT    = 2;  // Critical: critical conditions
const ERR     = 3;  // Error: error conditions
const WARN    = 4;  // Warning: warning conditions
const NOTICE  = 5;  // Notice: normal but significant condition
const INFO    = 6;  // Informational: informational messages
const DEBUG   = 7;  // Debug: debug messages

0-3 are system stoppers, 4 is a potential problem, 5-7 are more informational than actual issues.

So the question gets raised, how do we restrict system log logging to a particular error level?

Following the link to the other StackExchange question gives us two methods, the first is a change to error_reporting() in index.php, however; the second is much more flexible and also will help answer "where is all this coming from?".

The Firegento Logger Module (github repository) is a Advanced Magento Logger that has some really nice features.

  1. It allows you to limit down the log level so you're not getting a lot of informational and debug messages cluttering up the log file

  2. It has an advanced configurable log format that gives much more information about the error like the request that lead to the error message, the file that faulted, what the warning or error message was and limiting down stack trace dumps to as few lines as is really necessary to help with debugging.

  3. The ability to send the logged information elsewhere to Syslog or other services so the error messaging is stored off server for better security in the case of a security breach.

| improve this answer | |
  • Hi, thank you very much for tour reply, I have runned grep -r "</config>" * with 445 results and grep -r "</config>" * with 454 results. grep -r "<config/>" * were 3 but not useful,I will compare the results, is it a good way to proceed? – Razorphyn Oct 6 '14 at 5:49
  • Grep for <config></config> as the one mention is an empty config node in a template or configuration XML file somewhere. – Fiasco Labs Oct 6 '14 at 7:24
  • Hi, I ahve pdated the question with the results – Razorphyn Oct 6 '14 at 14:13

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.