Tickets :: Comment on [#9745] Upgrading overwrites backends.php

* Your Email Address
* Spam protection	Enter the letters below: . .___.__ __ __. \| [__ [__)/ `(__ \|___\| \| \\__..__)
Comment	> Still think this change is a terrible idea. Didn't dwell on the > subject on dev@ > (http://lists.horde.org/archives/dev/Week-of-Mon-20110214/025823.html) since > it seemed I was outnumbered, but the concerns I raised (or were > thinking about) are starting to show themselves so I will at least > mention a few more here. > > First, this is a huge, not readily apparent, change from H3. I've > been getting hammered lately for making changes that change the > status quo from H3 because this is what users/admins are "used to". > Don't see how this is any different. > > Adding a disclaimer to the config files is not going to change much. > Especially since I agree with Chuck - the location of the disclaimer > now pretty much means that nobody is going to see it, especially if > they are used to dealing with H3 configs. But even if you move it > closer to the actual PHP code, people are still going to ignore. > After all, if it was me, I'm going to open up the config file, search > for a string, and start editing anyway. > > Second, I can only imagine the e-mail support in the future on the > mailing list. Right now (H3), an email in a support thread might say: > > Edit horde/config/registry.php and add a 'status' entry to the ingo > block. The valid list of status options can be found at the top of > the file. > > In the future, this is what it will entail: > > Open horde/config/registry.php and determine the full PHP array > variable string (in this case $this->applications['ingo']['status']). > Also, make sure you check the top of that file for the various > status entries and remember this value. Then open > horde/config/registry.php.local. If this file doesn't exist, you > will need to create this file. Make sure this file is readable by > the user the PHP process is running as. Then make sure > horde/config/registry.php.local begins with this exact string: "<?php > ". Now you can paste the PHP variable string into this file, along > with the value that you should have determined when looking at the > original configuration file. You will probably want to comment this > entry also since, in isolation, you will likely forget the context of > this change in the future.
Attachment
Watch this ticket

Saved Queries