#3856 - Addon isolation via virtual subtrees
-
By Chris Graham
- Added
- 4 views
| Identifier | #3856 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Addon isolation via virtual subtrees |
| Status | Open |
| Tags |
Roadmap: Over the horizon (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | Composr installs all addons into a shared file tree.
This is good to create one maximally simple integrated system, and good for performance. There are cases where you may instead want to keep addons apart: 1) so that they can easily be enabled/disabled 2) so that conflicting overridden files don't overwrite each other 3) just so you can better see what files are in an addon without having to reference the addon_registry hook (perhaps in your IDE for example) Instead we could optionally have many virtual subtrees automatically merged into the main tree using a PHP virtual filesystem. I think new addons could be picked up automatically be analysing the subtree. This would be off by default, except perhaps in development mode. Also when addons are installed it could give the option to install them into a subtree instead of the main tree, with a precedence. Regardless of whether addons are installed in the main tree or a virtual subtree, a virtual filesystem would allow us to toggle addons on/off. Regarding point '2', the system of setting addon precedence is a basic resolution to it. But it's not a perfect solution. .php and .ini files can be merged by Composr at a function/class/string level. This is only good if the same functions aren't overridden of course. And for .tpl files, there's no way to merge. What would be really smart is if Composr could diff overrides against a .editfrom file, and then apply themselves as patches to the original files. It would not be perfect, but it'd help. |
| Steps to reproduce | |
| Related to | #3147 - Review of cloud filesystem support #3049 - Major upgrade reimagining (including hypervisor, and default theme improvements) |
| 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
We could make it an option in the installer whether to have a small number of important addons enabled, or all bundled addons. That way new users can avoid being overwhelmed.
An alternative would be to provide a virtual view via Commandr-FS/WebDAV, although it would not get all the same advantages discussed here.
Yet another potential would be to have a script that allowed creating a big structure of symlinks outside the Composr directory. I actually like this a lot, it takes the overhead out of Composr and just makes this all a developer niceity. Again though, it doesn't have all the advantages described here, but perhaps some of those advantages could be attained in other ways anyway.
I agree if we implement sub-tree support, it should *always* be used. There are many issues we might face if we allow switching between the two, especially with permalinks / URL rewriting.
Possible way to go about this is to change the Composr directory structure entirely...
1) In the root of Composr are all the files that were there before... _config.php, .htaccess, index.php, and so on.
2) Every addon (including core) is its own directory immediately under root. And it contains its own Composr structure of lang, comcode, pages, themes (except templates_cached), zone folders, etc. We'll need to discuss if _custom folders would still be necessary because ideally you'd put anything custom in a new addon. At this point, _custom would only override the specific addon's code.
3) Pages / zones / themes / overrides (which apply globally) not created as part of an addon would go under a "custom" directory immediately under root. These files can later be moved into an addon-specific folder when someone uses the export addon tool.
4) Composr would still contain core folders not pertaining to a specific addon, like caches, temp, safe_mode_temp, possibly imports and exports, immediately under root. It would also include uploads as-is because there is no compilation involved with those.
5) Composr would have a new "compiled" folder which compiles together (when needed) everything from all the sub-directories, and does so in a very similar structure to what Composr uses now (minus the custom folders). The exceptions are folders not addon-specific (caches, safe_mode_temp, temp, etc.), themes (except it will contain the cached / compiled templates of each theme), and uploads. This acts as a cache but is also the files which are actually executed / run. Resources are re-compiled when the smart cache thinks something changed in any of the directories. Self-learning cache would aid in tracking maps between files for compilation. A cleanup tool allows the cleanup of these files at any time.
The compiled folder would be git ignored.
This is a super modular way of doing things, but I think it would work out nicely. However, the biggest caveat would be URLs. Since all the pages would now be located under a "compiled" folder, something like adminzone/index.php would no longer work without mod_rewrite. Everything would have to point to the root index.php file for pages, and index.php would have to guide where to go from there.