#5645 - Re-design how $SITE_INFO works
-
By PDStig
- Added
- 7 views
| Identifier | #5645 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Re-design how $SITE_INFO works |
| Status | Open |
| Tags |
Roadmap: Sponsorship (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | The current system of _config.php is not very reliable when you factor in switches for git branches and hostnames. I propose instead of a single _config.php file, we use a similar override system to the sources scripts. * Have a new site_info directory (no need for site_info_custom as addons would not override these). * site_info contains default.php, which is the default configuration used (e.g. the old _config.php and the one checked to see if Composr is installed). This one is always loaded up, and is the first one to be loaded. That way, overrides are loaded in later which will change relevant variables to what they should be based on the override. * both site_info contains git_branch and hostname directories for specifying PHP files to act as overrides based on git branch or by hostname. For example, site_info/git_branch/v11.php would be loaded in when running on the v11 branch of git. site_info/hostname/somesite_com.php would be loaded in when the hostname is somesite.com. * config_editor would be modified accordingly to specify which config file to edit. (should be renamed to site_info_editor) Note that this interface should omit variables which were left blank on the interface (e.g. use whatever is provided in default.php, or what the software default is if not specified there either). But have some validation when editing default.php to ensure required variables are saved. |
| Steps to reproduce | |
| Additional information | When the installer is run, it overwrites _config.php which may have contained switch conditions based on git or hostname criteria for determining which config to use. It's a pain to have to keep merging these in after every clean install during development. And I believe a directory structure would make keeping these configs more organised. Also we should stop calling it "config" as that can get confused with the software configuration. It used to be called "info". I think it should match what the global is... "site info". |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
1) It's very late in v11 to be making such a large change to how Composr is configured. Scope creep has to be avoided unless it is creating a significant hurdle for the development team / maintainability / adoption, otherwise v11 will never be done/stable. This seems to me to be a minor annoyance at worst.
2) Upgrading sites to use the new configuration will introduce a lot of complexity. Every script like config_editor.php would need to be changed to reference the new more complex series of files; either needing to share code (in which case they are no longer standalone which was an important design consideration), or having a lot of copy and pasted code.
3) Adding a multi-config-file UI to config_editor.php is a lot more code that has to be maintained, tested, etc, and only for developers who would be perfectly capable of (and probably prefer) hand-editing files anyway.
4) Just the nature of this is adding complexity to the system for what seems a rare use case. Composr is intentionally designed to try and avoid too much developer-centric complexity from leaking into the simplicity of the design of the system exposed to the user. i.e. the default structure should be as simple as possible, and then if there's complexity that should be layered on. Having another layer of directory structure burying where the config file in is complexity.
5) Reinstalling a site during development seems odd. Normally you would update database structures on the fly as the production site would need to update itself. I'm not really sure there is a legitimate use case, perhaps you could explain.
6) "Info" was intentionally renamed to "Config" as "Info" really doesn't explain what it is, i.e. it isn't just 'info'. The user-experience is more important than the code being consistent, and if anything should be fixed it should be the code to use something better than SITE_INFO such as BASE_CONFIG (but that's a big compat issue too).
A much simpler solution would just have a new key in the config file that locks the file during installation, so that the database etc can reinstall without writing out a new config file. Having some kind of message go out into the start of the installer saying that new settings won't actually save, as the config file is locked.
2,3) True. Do we even need a UI for it anyway? We could just have the template file explain each available option in a comment.
4) It's not as rare as it sounds. Of all the sites I am maintaining, at least half of them have special cases in _config.php. In web hosting, it's good practice to have both a live site and a test site, which means anyone with both would reasonably also have special cases in their config file (hostnames or directory controllers specifically).
5) It is (sometimes) necessary to have a clean install before running unit tests. Furthermore, I often make changes which are so breaking to my development install that I have no choice but to re-install (not even upgrader works). Also, changing git branches sometimes results in dirty working environments especially when switching between versions (git hooks have never worked for me; in fact they also don't work on compo.sr). This would require manually clearing out the caches, fixing permissions, etc, where a new install would just be faster (and more efficient) in most cases.
Note this is only within development installs. This is never an issue (e.g. I never have to do new installs) when transferring from development to production sites because I use addons / modules / the schema tool to do the updating (or hint at what needs done); I don't do on-the-fly manipulation for production sites. I don't trust myself to do that. It's bad practice. And it's better to have the schema incorporated into Composr when pushing to production so it can do its typical maintenance and integrity checks. So in that case, we can assume this is a very minor issue so long as others follow the same guidance for production database modifications.
6) That's fair. Info wouldn't be a good name either, I agree. And I can see why the global was never changed.
7) That won't work (unless it does a temporary config file). The settings won't apply / persist as necessary between installer steps. How about one of these:
* The user is prompted whether or not they want a new config file written (if not, installer uses a temporary config until the installer finishes), -or-
* Only settings which have been changed are saved into the config... and are appended rather than a totally new config file written.
"Do we even need a UI for it anyway?"
Yes, a documented fundamental principle of Composr is that regular users should never have to touch code to deploy the core featureset.
Besides, any kind of comments in there would become outdated over time, and new options are added over time, or available but not written out by the installer. Before we'd know it we'd be talking about some new system to keep rewriting the contents of these files with updated comments etc.
"Of all the sites I am maintaining, at least half of them have special cases in _config.php"
Those are all developer-centric cases, which are a minority in relation to the general userbase. As soon as a developer becomes involved, it's reasonable to add extra burdens of complexity for developers we would not have on regular users. But we'd only want developers to really see it. i.e. If a developer is managing development/staging/production sites, it becomes reasonable they then have to maintain the config file, with its now broadened complexity, rather than the end user.
This is one thing that hopefully sets Composr apart from something like Drupal - a default install is very streamlined, you don't need to be a software engineer to understand as much stuff. Complexity hopefully only comes in when treading away from the default path.
"It is (sometimes) necessary to have a clean install before running unit tests"
An aside: I try to say "automated tests" rather than unit tests. If we were doing true unit tests, it would work regardless of site state because we'd be mocking out the database calls, filesystem calls, etc.
What I would personally do in this situation is, just copy the config file to a backup, and put it back afterwards. But yeah, maybe my process sucked,
"This would require manually clearing out the caches, fixing permissions, etc, where a new install would just be faster (and more efficient) in most cases. "
I always just ran "sh decache.sh" in the terminal after switching branches in the same terminal. Permissions wasn't an issue as I had a suEXEC-like environment.
"Only settings which have been changed are saved into the config... and are appended rather than a totally new config file written."
I like that. You could just detect if the file has lines that don't match standard lines, and if so, always just append. Then you don't even need to explain this, it'd just work.
"An aside: I try to say "automated tests" rather than unit tests. If we were doing true unit tests, it would work regardless of site state because we'd be mocking out the database calls, filesystem calls, etc."
It would be difficult for me to adopt this language and remember it given the test suite itself (simple test) uses the terminology unit tests. But I will try to remember.
"What I would personally do in this situation is, just copy the config file to a backup, and put it back afterwards. But yeah, maybe my process sucked,"
I do this when I can (especially now that the installer makes a backup for you), but sometimes things go wrong especially when doing headless installs via testing. And I just have to start over with a new one.
"I always just ran "sh decache.sh" in the terminal after switching branches in the same terminal. Permissions wasn't an issue as I had a suEXEC-like environment."
On my local environment (Windows), I can't do this for v10. Now for v11 I can because it's a PHP script, but the flip side is it makes it more difficult for me to do on my server environment (because it doesn't have a typical distro PHP install... I have to find and use the full PHP path from Plesk each time). Nonetheless even when I run it, sometimes I still need to do a fresh install because of some database change or something.
"I like that. You could just detect if the file has lines that don't match standard lines, and if so, always just append. Then you don't even need to explain this, it'd just work."
I'll do this instead then (at some point). It is a much easier solution than my original proposal.