Hi Piotr, I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
Hi
Dne Wed, 21 Jul 2010 09:25:38 -0400 Marc Delisle marc@infomarc.info napsal(a):
I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
I don't think this should be by default configurable by user.
2010/7/21 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 21 Jul 2010 09:25:38 -0400 Marc Delisle marc@infomarc.info napsal(a):
I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
Then, I will add it but make disabled by default (add it to UserprefsDisallow in config.default.php). Or, I will create a hidden "developer" tab, with some settings (gather, php and sql debug). The tab would be visible only if any of its settings would be enabled (i.e. removed from UserprefsDisallow) in config.inc.php.
Piotr Przybylski a écrit :
2010/7/21 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 21 Jul 2010 09:25:38 -0400 Marc Delisle marc@infomarc.info napsal(a):
I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
Then, I will add it but make disabled by default (add it to UserprefsDisallow in config.default.php). Or, I will create a hidden "developer" tab, with some settings (gather, php and sql debug). The tab would be visible only if any of its settings would be enabled (i.e. removed from UserprefsDisallow) in config.inc.php.
Adding to UserprefsDisallow would be fine with me; this way we would use the same mechanism for many things, instead of a new mechanism for a hidden tab,
W dniu 21 lipca 2010 17:52 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
2010/7/21 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 21 Jul 2010 09:25:38 -0400 Marc Delisle marc@infomarc.info napsal(a):
I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
Then, I will add it but make disabled by default (add it to UserprefsDisallow in config.default.php). Or, I will create a hidden "developer" tab, with some settings (gather, php and sql debug). The tab would be visible only if any of its settings would be enabled (i.e. removed from UserprefsDisallow) in config.inc.php.
Adding to UserprefsDisallow would be fine with me; this way we would use the same mechanism for many things, instead of a new mechanism for a hidden tab,
I added a new Developer tab with four options: Error_Handler display and gather, DBG php and sql. Tab is hidden if none of those options is settable by the user (by default all are disabled in config.default.php).
Please modify demo server's config.inc.php to enable this tab and disable something other: $cfg['UserprefsDisallow'] = array('LeftFrameLight'); // or any other setting(s), so that some disabled setting is actually visible there
Piotr Przybylski a écrit :
I added a new Developer tab with four options: Error_Handler display and gather, DBG php and sql. Tab is hidden if none of those options is settable by the user (by default all are disabled in config.default.php).
Please modify demo server's config.inc.php to enable this tab and disable something other: $cfg['UserprefsDisallow'] = array('LeftFrameLight'); // or any other setting(s), so that some disabled setting is actually visible there
Piotr, with this in my config.inc.php $cfg['UserprefsDisallow'] = array( 'Error_Handler/gather');
I see the Features/Developer tab, this is OK. However when I am in the user prefs pages, notices are always displayed (it's like "display errors" is always true in these pages.
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
W dniu 22 lipca 2010 15:14 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
I added a new Developer tab with four options: Error_Handler display and gather, DBG php and sql. Tab is hidden if none of those options is settable by the user (by default all are disabled in config.default.php).
Please modify demo server's config.inc.php to enable this tab and disable something other: $cfg['UserprefsDisallow'] = array('LeftFrameLight'); // or any other setting(s), so that some disabled setting is actually visible there
Piotr, with this in my config.inc.php $cfg['UserprefsDisallow'] = array( 'Error_Handler/gather');
I see the Features/Developer tab, this is OK. However when I am in the user prefs pages, notices are always displayed (it's like "display errors" is always true in these pages.
My debug code, I just commited code with it removed.
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Piotr Przybylski a écrit :
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
W dniu 22 lipca 2010 17:19 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
If we already got there let's finish it :)
Moving it to another config key, let's say UserprefsDeveloperTab (boolean), would simplify things - no more meddling with UserprefsDisallow, just a simple "if ($cfg[UserprefsDeveloperTab])" in form definition file.
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:19 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
If we already got there let's finish it :)
Do you see a reason to hide the Features/Developer tab by default?
Moving it to another config key, let's say UserprefsDeveloperTab (boolean), would simplify things - no more meddling with UserprefsDisallow, just a simple "if ($cfg[UserprefsDeveloperTab])" in form definition file.
W dniu 22 lipca 2010 17:29 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:19 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
If we already got there let's finish it :)
Do you see a reason to hide the Features/Developer tab by default?
I just believe that only developers may use it so users shouldn't be bothered with something they will never use.
Moving it to another config key, let's say UserprefsDeveloperTab (boolean), would simplify things - no more meddling with UserprefsDisallow, just a simple "if ($cfg[UserprefsDeveloperTab])" in form definition file.
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:29 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:19 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
Also I don't understand your reference to array_merge() in config.default.php. I believe someone would just list which prefs he wants to disallow, in config.inc.php, in a neat list of array elements, right?
I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
If we already got there let's finish it :)
Do you see a reason to hide the Features/Developer tab by default?
I just believe that only developers may use it so users shouldn't be bothered with something they will never use.
Moving it to another config key, let's say UserprefsDeveloperTab (boolean), would simplify things - no more meddling with UserprefsDisallow, just a simple "if ($cfg[UserprefsDeveloperTab])" in form definition file.
OK, use UserprefsDeveloperTab until we come up with a better idea.
W dniu 22 lipca 2010 17:46 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:29 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
W dniu 22 lipca 2010 17:19 użytkownik Marc Delisle marc@infomarc.info napisał:
Piotr Przybylski a écrit :
> Also I don't understand your reference to array_merge() in > config.default.php. I believe someone would just list which prefs he > wants to disallow, in config.inc.php, in a neat list of array elements, > right? I want to make sure that if any option gets added there in config.default.php, user's config.inc.php will remain valid.
Another solution I can think of is to add a new config option, which would allow to enable Developer tab without using UserprefsDisallow. Should I do that?
Things are starting to get complex and I'm starting to regret suggesting this feature :)
Let's take a step back for a minute. I don't see the point of hiding the Features/Developer tab, therefore I don't see the necessity of putting these values by default in UserprefsDisallow.
If we already got there let's finish it :)
Do you see a reason to hide the Features/Developer tab by default?
I just believe that only developers may use it so users shouldn't be bothered with something they will never use.
Moving it to another config key, let's say UserprefsDeveloperTab (boolean), would simplify things - no more meddling with UserprefsDisallow, just a simple "if ($cfg[UserprefsDeveloperTab])" in form definition file.
OK, use UserprefsDeveloperTab until we come up with a better idea.
Done
Michal Čihař a écrit :
Hi
Dne Wed, 21 Jul 2010 09:25:38 -0400 Marc Delisle marc@infomarc.info napsal(a):
I wonder if $cfg['Error_Handler']['display'] should be made available in a setting.
I'm ambivalent about this one. As a developer I would like to be able to turn it on and off; on the other hand, we don't want to promote information disclosing.
I don't think this should be by default configurable by user.
I guess you mean a user that has no access to config.inc.php? This can be disabled by default with the UserprefsDisallow as suggested by Piotr.