prashants
Make configurations upgrade-friendly.
The recent translations commit (52d91d4) suggests that end users modify configuration files that will be overwritten when they upgrade. This makes it expensive for users to update, which could lead to security holes and other problems.
Moving to a model where configurations are stored on separate files that don't get overwritten (i.e. a file that doesn't exist in the repository and is only auto-generated if needed) would make it easier for people to upgrade to new versions of the software.
I haven't taken a full stock of the scope of changes that would need to be made, but it is definitely the road to move towards and has been adopted by many major web applications.
For reference, in order to be upgrade-friendly the biggest rule is that deployment shouldn't involve modifying any project ('core') files. That way everything can get overwritten on a new installation and still work fine.
The change was just for testing. Plan is to have per user language selection that will be saved in the user database :)
That’s a good move, maybe with a site default. We also need fixes for things like Config/config.php and Database/webzash.sqlite, which are important.
On Dec 28, 2015, at 10:04 AM, Prashant Shah [email protected] wrote:
The change was just for testing. Plan is to have per user language selection that will be saved in the user database :)
— Reply to this email directly or view it on GitHub https://github.com/prashants/webzash/issues/50#issuecomment-167616046.
Well, the webzash.sqlite could be solved using the default included SQLite3 library. See: http://php.net/manual/en/sqlite3.open.php. Looks like it will auto create it. Then you just have to detect that there isn't any structure and build it.
I was thinking of removing the sqlite dependency, use a installer and use mysql for user information.
In that case you might move to a global database model where you don’t have to enter in database details for each individual account. That would also make it a lot more user friendly as well.
On Dec 28, 2015, at 10:24 AM, Prashant Shah [email protected] wrote:
I was thinking of removing the sqlite dependency, use a installer and use mysql for user information.
— Reply to this email directly or view it on GitHub https://github.com/prashants/webzash/issues/50#issuecomment-167620769.
Doing that will not be possible. Since entering database details is only once that you have to do every year.
I’m confused why it wouldn’t be possible? You’d need to change the prefix on a per account basis? If that’s the issue, then just have the user enter in that information and not have to dig up their username and password.
Also, you’re assuming one account. If I have five accounts that all end at different parts of the year, I’d have a problem.
On Dec 28, 2015, at 10:30 AM, Prashant Shah [email protected] wrote:
Doing that will not be possible. Since entering database details is only once that you have to do every year.
— Reply to this email directly or view it on GitHub https://github.com/prashants/webzash/issues/50#issuecomment-167622462.
Well … not a ‘problem’, but an inconvenience.
On Dec 28, 2015, at 10:32 AM, Tyler Carter [email protected] wrote:
I’m confused why it wouldn’t be possible? You’d need to change the prefix on a per account basis? If that’s the issue, then just have the user enter in that information and not have to dig up their username and password.
Also, you’re assuming one account. If I have five accounts that all end at different parts of the year, I’d have a problem.
On Dec 28, 2015, at 10:30 AM, Prashant Shah <[email protected] mailto:[email protected]> wrote:
Doing that will not be possible. Since entering database details is only once that you have to do every year.
— Reply to this email directly or view it on GitHub https://github.com/prashants/webzash/issues/50#issuecomment-167622462.
My solution to solving the Config/config.php issue can be found in issue #51