Ticket #374 (closed defect: fixed)

Opened 2 months ago

Last modified 2 months ago

Config $CFG->debug handling is broken

Reported by: eavdmeer Assigned to: nobody
Priority: highest Milestone: 0.9.3
Component: core Version: 0.9.1
Severity: critical Keywords: debug
Cc: Patch Included: 1
Review Stage: unreviewed

Description

The get_config() function uses the prefix_datalists table to read the $CFG->debug value. If this value is set in config.php as well, the database value overrides the config.php value because it is read later. The documentation of the get_config() function falsely states that it will not overwrite existing config values. Due to a patch by someone with initials 'Rho', the $CFG->debug value is overwritten. The admin panel (mod/elggadmin/index.php?view=all) shows the value from config.php as read only, but the code actually uses the value from the database. This completely brakes debugging when the config.php variable is used.

Reproduce: make a standard install of elgg. Then edit config.php and add:

$CFG->debug = E_ALL; // Sets all debugging, value 2047

Now open the admin panel. It will show 'show all errors' in the debug section. If you create a deliberate error somewhere in one of the modules, you should be able to verify that debugging is actually turned off completely due to the value '0' in the prefix_datalists table.

Attachments

debug.patch (0.8 kB) - added by eavdmeer on 06/20/08 12:25:31.

Change History

06/20/08 12:25:31 changed by eavdmeer

  • attachment debug.patch added.

06/24/08 09:02:37 changed by eavdmeer

Forget about the patch! It will make debugging work well, but it will break important things like the site name, which is set to a default value in config-defaults.php. It *must* be overridden by the value in the database.

I don't really know how to fix this, but I have the feeling that the values in the config.php file should always the last resort value; the only way to make sure you know what the values are. For that to work, they should be included after reading the database values. However, we have a chicken-egg dilemma there because the database config is in config.php....

06/27/08 07:47:57 changed by rho

Are you using latest?

Because there is some fixes about the handling of manual config vs database stored config.

See [1607] and [1589]

06/27/08 08:03:38 changed by eavdmeer

  • status changed from new to closed.
  • resolution set to fixed.

I'm not using latest, because I use elgg in a production setup. Looks like the fixes in handling of manual config will do the trick. I'll close the ticket. Thanks.