Magento 1.x SUPEE-11086 Bug – Mage::log stops writing data

It’s good to keep your Magento installation up to date with security patches. But like usual, be ready to catch a bug or two from them…

Mage::log broken with patch SUPEE-11086

With SUPEE-11086 I’ve so far found that calls to Mage::log no longer write data to the log files. They seem to have crippled this function by accident for my installation…

Source of the Bug

In app/Mage.php they made this change:

This change looks to your stores configuration for a list of what file extensions are approved for logging (comma separated). However this configuration doesn’t exist… It should be in the database (or I believe could be defined in XML).

Magento could/should have added an option to configure this is the Mage Admin in my mind with this patch.

Solution (let’s start writing data again!)

The solve is actually quite simple. We need to add the configuration to the database and clear the cache.

  • Add entry to the database (core_config_data table)
    • INSERT INTO core_config_data VALUES ( NULL, 'default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv' );
  • Clear the object cache
    • via the Magento admin or command line
  • Verify log files are writing again (look at timestamps)
    • ls -lrt var/log/ | tail

Tested Version

Magento Enterprise Edition with all security patches applied.

I applied when applying the SUPEE-11086 patch.

Magento’s Support / Response to this Bug

I have an open ticket with Magento Support. I’ll update if/when I hear a response.

Magento Ignored Existing Code?

Odd/sad that Magento didn’t reuse existing code for validating log file extensions that they added via SUPEE-10415 in late 2017.


Resolution / Update

It turns out this was a case of user error…. (not sure how I could have done that!!! ha!) But others may run into this as well and thus I’m leaving this post active.

I have the main codebase in one git repo. I have a second git repo for configuration which includes the file app/etc/config.xml which was part of the patch. But when I deployed the change this configuration did not get pushed live. Once I updated the XML file and I removed my added config from the database all still worked as expected (and flushed cache of course).