constant value for website/WEBSITE is stored in database table _config

[torvista]

While testing locally, I noticed a link to the unsubscribe page was pointing to the real hosted site instead of the local site. This link (for example) traces back to the value of "website" in the db table phplist_config. I believe the database should be 100% portable and anything installation-specific should be in the config FILE. Having this constant in the database renders the database non-portable and makes all links based on this constant incorrect as per my first observation. I would extend this point of view to other parameters in the admin configuration like email server and admin email addresses to use, to allow a fully independent installation to be used for testing, so requiring NO database modifications/changes when importing a production database to a development/local environment for functionality testing.

[samtuke]

@torvista Thanks for reporting this. The challenge is to make it easy for settings which are commonly changed to be editable via the UI, while also making the config file the primary source of truth for important settings and keeping installations portable. It would be possible to store some settings from the Settings page in the config file, and others in the database, but that would introduce uncertainty about where to look when manually changing those values. Perhaps the settings could be grouped to indicate where they are stored on that page (in the UI).

Would you be interested in working on introducing this functionality? E.g. the writing of certain values on the Settings page to the config.php file?

FYI @michield

[torvista]

While I always am keen to contribute to improvement of most things, I am so buried under my own business/affairs that I cannot even get round to doing essential work on my own online shop, so my efforts are limited to constructive criticism. I would just say move all installation-specific items to the config, but allow them to be viewed from the UI so it's obvious where they are located. Do whatever is necessary to make the db portable without needing to think .

[michield]

The reset settings link in the configuration page will reset the settings from the location where it is installed. Putting that in the config file makes it harder to configure for some other situations. Currently it will pick it up from the environment at install time.

I agree it would be nice to allow a simple refresh to a development environment. I think we should make this a feature request. The reason it is in the DB is that the Web UI has access to the value, but the CLI does not and has to read it from the DB. Probably some command to run after a refresh would be the best route to go.