typo in lib/config-defaults.php

Bug #738265 reported by Scott Korvek
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
Fix Released
Medium
Richard Mansfield

Bug Description

I found a config file error (wrong case on the error log.. CFG-> vs cfg->) which was copied over from lib/config-defaults.php -- so that's a minor typo in your lib/config-defaults.php file with big consequences; and thus another easy-to-fix bug.

Forum post with complete details: http://mahara.org/interaction/forum/topic.php?id=3110#post13442

Revision history for this message
François Marier (fmarier) wrote :

Thanks for that, fixed!

Changed in mahara:
milestone: none → 1.4.0
importance: Undecided → Medium
assignee: nobody → François Marier (fmarier)
status: New → Fix Committed
Revision history for this message
Richard Mansfield (richard-mansfield) wrote :

This wasn't a typo actually, it's there for a reason. config-defaults.php resets $cfg at the top, so $cfg->dataroot is undefined in the place where it sets that log_file property; $CFG on the other hand is a global defined in init.php, so $CFG->dataroot is available.

I think this problem occurred because config-defaults.php got copied, but as I think it says somewhere in the docs, you shouldn't be copying config-defaults.php to create your config.php, you should copy config-dist.php instead.

Revision history for this message
François Marier (fmarier) wrote :

Oops. Commit reverted on master.

Changed in mahara:
status: Fix Committed → Invalid
milestone: 1.4.0 → none
Revision history for this message
Scott Korvek (sjk6574) wrote :

So what should my config.php be? With it set CFG, I get errors until I change it to cfg. I didn't copy config-defaults.php, I copied the one line from config-defaults that sets that directive, since it isn't in cfg-dist.php and I needed the logging to troubleshoot the original error.

Revision history for this message
Richard Mansfield (richard-mansfield) wrote :

Scott,

Yeah I had another look and you're absolutely right, there are some *serious* problems with these files.

I'm wondering, were you talking about the $cfg->log_file line or the $cfg->emaillog line? Because it seems to me that there *is* a typo for $cfg->emaillog in config-defaults.php and that it should probably say

// $cfg->emaillog = $CFG->dataroot . '/log/email.log';

But anyway, config-defaults clearly says at the top "If you see a setting in here you'd like to change, copy it to your
config.php and change it there", which is a lie in the case of the $cfg->log_file line as you discovered, because $CFG->dataroot is going to be undefined inside config.php.

Maybe that comment should be removed, and all the commented-out stuff in config-defaults should instead go into config-dist.

Or maybe we could just add in a hacky comment above the $cfg->log_file line to say you need to change $CFG to $cfg if you're moving it into config.php.

In your case I guess if you're just wanting to change $cfg->log_file in config.php you need to reference $cfg->dataroot and obviously put it below the line where you set $cfg->dataroot. (I'm not familiar with $cfg->log_file and LOG_TARGET_FILE, I've always just let it all go to the apache log).

Changed in mahara:
status: Invalid → Confirmed
milestone: none → 1.4.0
assignee: François Marier (fmarier) → Richard Mansfield (richard-mansfield)
Revision history for this message
Ruslan Kabalin (rkabalin) wrote :

As an option, we may ask people to use full path in $cfg->emaillog since it is not the option that often used. And if it is in use, the most reasonable place for mahara logs should be /var/log/mahara rather than data directory I think (users should care about correct permissions for www-data user of course). So, having that $CFG->dataroot in the path by default does not make much sense apart of the presumption that it should work out of box without file-system permissions changes.

Changed in mahara:
status: Confirmed → Fix Committed
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.