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