I wanted to accomplish in CI4 what I was doing in CI3 - have a system folder that was shared by multiple sites/projects and upgrade them individually as their code became (or was confirmed as) ready for the new version.
Using this approach, when a new release of CI3 was available, I would immediately install the new framework, but this wouldn't affect any existing code. Only when I was ready, I would point a site/project to the new system code, and I could revert that immediately and fully if something failed in a major way.
I think I have this working in CI4, but I'd like to know if anyone sees problems or concerns with how I'm doing this now. Life's been too busy for me to deal with upgrading things from CI3, but I'm now at a point where I can't delay further, thus the timing of this question.
In the following, structures assume a manual installation. I don't use Composer and have no idea how this would impact Composer-installed CI4.
The differences between how I'm doing this and what the documentation suggests are file organization and using an absolute path to the system folder in Config/Paths.php
The documentation suggests the following structure for a manually-installed multi-site CI4:
Code:
foo/
app/
public/
tests/
writable/
env
phpunit.xml.dist
spark
bar/
app/
public/
tests/
writable/
env
phpunit.xml.dist
spark
codeigniter4/system
My approach, allowing multiple CI4 system/core versions, looks like this:
Code:
foo/
bar/
ci4_5_8/
ci4_6_0/
ci4_6_1/
(I'm actually starting at 4.6.1, so the older versions there are just for illustration.)
In Paths.php I have:
Code:
public string $systemDirectory = '/server/projects/ci4_6_1';
I think this explains enough, but let me know if you have questions about what I mean. My question is: are there any risks (especially regarding security or stability) here that I should be wary of? It seems like a straightforward variation, but dealing with framework code that I don't have time to analyze in depth makes me a little nervous about variations.
