interfasys Posted August 10, 2014 Report Posted August 10, 2014 I don't know what the best solution to avoid the problem would be, but _custom.php should never be overwritten during an upgrade, because we lose all our custom English language definitions that way. Either you teach Blesta how to read another custom file or you provide a _custom.php.example file that you can rename during the installation/upgrade process if the file doesn't exist.
Blesta Addons Posted August 11, 2014 Report Posted August 11, 2014 this is not a bug , i think this is feature that can be added .
interfasys Posted August 11, 2014 Author Report Posted August 11, 2014 How is it not a bug if we lose everything after an update?
interfasys Posted August 11, 2014 Author Report Posted August 11, 2014 And it's not just languages which are affected, custom routes disappear as well.
Tyson Posted August 11, 2014 Report Posted August 11, 2014 Each core file is subject to being updated/overwritten on upgrade, including, but not limited to, the config file. If there are custom changes that you've made and that you want to persist, you should be mindful of those changes and merge them in with any upgrade you're performing.
Michael Posted August 11, 2014 Report Posted August 11, 2014 How is it not a bug if we lose everything after an update? Because what people like myself do if we customised it is extract the zip, remove the files which will overwrite and upgrade, but in patches only plugins may be overwritten, there's no routes. If you custom something you expect a little bit of manual labour.
interfasys Posted August 11, 2014 Author Report Posted August 11, 2014 Because what people like myself do if we customised it is extract the zip, remove the files which will overwrite and upgrade, but in patches only plugins may be overwritten, there's no routes. If you custom something you expect a little bit of manual labour. I disagree. Of course, it's not difficult to write patches, update scripts, etc., but we're not talking modifying the core here, but configuring or perhaps customising an installation using documented switches and configuration files put at our disposal. Other projects have php.sample files which we rename to personalise or look for .local files and use that. Of course, one has to port changes made to these files, but they're usually only touched when there is a major upgrade. Maybe the documentation needs to be updated. In my opinion, you can't just say, put your customisations here and then wipe the file.
Tyson Posted August 12, 2014 Report Posted August 12, 2014 The _custom language file has definitions in it that are used in the core of Blesta as well, so any changes made to those would require an update to the file anyway. But it sounds like you want to avoid merging customizations where possible. Since Blesta only loads what it needs when it needs it, simply renaming a file to anything you want wouldn't work. What might be a better solution is a setting, or configuration value, to specify your user-defined language file, and possibly when to load it.
interfasys Posted August 12, 2014 Author Report Posted August 12, 2014 Yeah, I think loading another custom.php file which doesn't get overwritten would work and in the meantime, maybe a warning in the doc regarding the fact that _custom.php gets overwritten with every update.
Tyson Posted August 25, 2014 Report Posted August 25, 2014 Closing this thread as not a bug. You may want to create a feature request thread about a new custom language file if there isn't one already.
Recommended Posts