View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 3856 | Composr | core | public | 2019-07-22 19:15 | 2024-09-07 02:48 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 3856: Addon isolation via virtual subtrees | ||||
| 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. | ||||
| Tags | Roadmap: Over the horizon | ||||
| Attach Tags | |||||
| Time estimation (hours) | 100 | ||||
| Sponsorship open | |||||
| related to | 3147 | Closed | Chris Graham | Review of cloud filesystem support |
| related to | 3049 | Not Assigned | Guest | Major upgrade reimagining (including hypervisor, and default theme improvements) |
| related to | 4052 | Resolved | Chris Graham | Logging framework |
| related to | 5473 | Resolved | PDStig | v12: Consider *_compiled directories |
|
|
Perhaps we wouldn't give the option for addons to be in a virtual subtree - they always would be, including on git. That would definitely make things less overwhelming to developers. Right now there are a lot of files under sources/. 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. |
|
|
Note that Cloud-FS gives Composr a virtual filesystem for the purpose of cloud deployments, and also shared installs. Perhaps we should look at potentially extending that. 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. |
|
|
This solution would also probably solve the issue of adding overrides to non-bundled addons. Currently, non-bundled addons store all of their code in _custom directories. The only way to effectively override a non-bundled addon is contentious overrides in v11, or just editing the file manually. These solutions might not be ideal in v12 when we introduce 3049 and automatic updating of non-bundled addons . |
|
|
Thinking this through more... 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-07-22 19:15 | Chris Graham | New Issue | |
| 2019-07-22 19:25 | Chris Graham | Relationship added | related to 3147 |
| 2020-01-26 22:55 | Chris Graham | Relationship added | related to 4052 |
| 2020-02-23 00:02 | Chris Graham | Note Added: 0006439 | |
| 2021-04-04 00:28 | Chris Graham | Tag Attached: Roadmap: v12 | |
| 2022-07-28 03:03 | Chris Graham | Note Added: 0007399 | |
| 2024-01-27 20:09 | PDStig | Relationship added | related to 5473 |
| 2024-01-27 20:23 | PDStig | Note Added: 0008256 | |
| 2024-01-27 20:23 | PDStig | Note Edited: 0008256 | |
| 2024-01-27 20:24 | PDStig | Relationship added | related to 3049 |
| 2024-03-26 00:58 | PDStig | Tag Renamed | Roadmap: v12 => Roadmap: Over the horizon |
| 2024-09-07 02:43 | PDStig | Note Added: 0009308 | |
| 2024-09-07 02:46 | PDStig | Note Edited: 0009308 | |
| 2024-09-07 02:48 | PDStig | Note Edited: 0009308 |
