@oupala Please give it a try if you can

Some of the distributions might have to change a path if they do anything special with those default configuration files:

• Moved ./data/force-https.default.txt to ./force-https.default.txt,
  ./data/config.default.php to ./config.default.php,
  and ./data/users/_/config.default.php to ./config-user.default.php

Any comment from Cloudron (@dswd), DPlatform (@j8r), YunoHost (@plopoyop) ?

Since Yunohost is only using the cli interface, it won't change anything for yunhost package.

I just checked my Cloudron package code and it seems I am using the cli too.

Thanks @Alkarex , a line need to be changed on DPlatform. These paths are clearer than the previous ones 👍

@Alkarex I can test for sure. But what should I test? The install process, the usage after installation? The usage with my own data directory?

@oupala If you just try the /dev branch for your own case, that will do it :-)

I tested your fork (Alkarex/FreshRSS branch dev) and I end up with so many configuration files:

>find -L FreshRSS-dev/ -name "*config*"
FreshRSS-dev/config-user.default.php
FreshRSS-dev/config.default.php
FreshRSS-dev/data/users/_/config.default.php
FreshRSS-dev/data/users/<user>/config.php
FreshRSS-dev/data/config.php
FreshRSS-dev/data/config.default.php

Is it normal to have so many configuration files?

Even after a clean install (no user data directory), there is 4 configurations files!

>find -L FreshRSS-dev/ -name "*config*"
FreshRSS-dev/config-user.default.php
FreshRSS-dev/config.default.php
FreshRSS-dev/data/users/<user>/config.php
FreshRSS-dev/data/config.php

It becomes hard to say where is the configuration stored.

Yes, that looks fine. There is a default set of settings for the system, and a default set of settings for a user. Those are not supposed to be edited by end-users. Then there is the settings of the concrete instance, and one configuration file per concrete user.

Ok, but then there is 2 configurations files in data directory.

How do you ensure that these files stay up to date? Are they both containing just the modified settings from the default ones?

In my case, the data directory is never updated by an upgrade. Is there an automated process to upgrade them whenever ansible upgrades the FreshRSS instance? (such as the cookie setting)

@oupala Sorry for the delay.
The files you are mentioning are user files. Yes, they override default settings. When a new property is introduced, it does not matter if it is not included in those files.
Very few changes are made during versions in the ./data/ directory, but a little bit, such as creating new sub-directories. Those things are done automatically by a ZIP update or git pull update. There is currently no mechanism to perform a partial update.
I have not yet seen an Ansible rule for FreshRSS, so I am not sure of the details.

Ok @Alkarex thanks a lot.

In my opinion, the data directory is the user domain. There should not be any update in this directory made by the upgrade process, at least not without warning the user.

With my ansible role, the data directory is never updated by the upgrade process. So if any of your upgrade needs an update in the data directory, you should add a BREAKING CHANGE in the changelog so that the user knows that he has to change something in the data directory.

./data/ is not (only) user domain. It is the sub-directory where FreshRSS (via the Web server) must have write access, while read access is enough for other directories.
I think everything you ask should be done via the CLI. Not everything is available through the CLI yet, though, so please open issues for the missing features you need.
https://github.com/FreshRSS/FreshRSS/tree/dev/cli

Thanks @Alkarex for pointing the difference between "user space" and "write access".

Can you help me to define where is the "user space" then?

My point is not about manually editing files. I do fully agree that all operation should be done via the CLI, which knows better that any human how to manage data.

My point is about separating the user data from the app data. When my ansible role installs a new release of FreshRSS, it installs it in a new directory (either by deleting the previous directory, or by creating a new directory). After that step, the ansible role creates a symlink to insert the user data so that the user can find all his settings, rss history, favorites articles, that he had on the old instance. This is only possible if user data are clearly separated from the app data, and if any breaking changed in user data are clearly documented (in the changelog).

From version 1.7.0, copying the content of your old ./data/ directory into the new ./data/ directory should be enough, and will also cover the case of new sub-directories created under ./data/.
Related to #907

Good point.

Will the following work?

• delete old FreshRSS directory
• install new version of FreshRSS
• delete new ./data directory
• symlink /somewhere-on-a-nas/freshrssdata/ to ./data

This way, it won't merge the two data directory, and new sub-directories won't exist after upgrade...

Could it be FreshRSS's responsibility to update a data directory when needed?