In Yii1.1 you could put the framework in a directory above /approot and use it for multiple sites. When updating the framework, you could do it in one place then all associated sites up update.
In looking through the Yii2 sites, the framework is no in /venders for each individual site. Is there a way of moving the framework to a common location for all sites on a server, or do we HAVE to have it in venders for individual sites?
Answered this in your other post about subdomains. Only a single copy of the framework in vendors/yiisoft/ is required using the advanced template or the alternate template I recommended. Create as many applications as required under the same root directory as backend, frontend, vendor, etc.
Maybe symlink app\vendor\yiisoft to a directory contained framework
Not necessary. In 1.x, Yii could be installed in a directory above the webroot. With the Kartik-v solution I mentioned, this is also the case. In the Advanced template, a web directory exists under each application. The recommended template from Kartik-v moves the frontend/web directory to the same level as vendor/ (becoming web/). The web backend/web/ directory is renamed to backend/ and moved under the web/ (becoming web/backend/). The separate web/ directories under each application are eliminated. Any new applications can be installed on the same directory level as frontend/ or backend/. All would use the same Yii installation under vendor/. The directory structure is basically the same as for 1.x. See below:
backend/
common/
console/
environments/
frontend/
vendor/
yiisoft/
yii2/ (single Yii 2.x install)
subdomain1 (start with a copy of frontend)
subdomain2 (start with a copy of frontend)
web/
assets/ (frontend assets)
backend/
assets/ (backend assets)
css/ (backend css)
index.php (backend index.php)
index-test.php (backend index-test.php)
css/ (frontend css)
subdomain1/ (same structure as admin)
subdomain2/ (same structure as admin)
index.php (frontend index.php)
index-test.php (frontend index-test.php)
The backend url becomes http://domain.com/backend/index.php, Subdomain1 becomes http://domain.com/subdomain1/index.php, etc. Add as many subdomains as required.
For a subdomain, point your virtual host to the new url and add a parameterized hostname route to common/config/main.php or main-local.php.
To convert an Advanced template to the Kartik-v solution, move the frontend/web/ directory to web/. Rename the backend/web/ directory to backend/ and move it under web/ (becoming web/backend/). Adjust the relative paths of index.php and index-test.php in the web/backend/ directory to reflect the directory move.
So what you’re saying mmx is that ALL of my apps need to be under one directory?
Sorry if my posts were confusing.
Correct. Both templates assume the application directories are at the same directory level as common, console, environments, and vendor. That is, the subdirectories need to be parallel to one another in order for relative paths to work as intended. Everything revolves around the relative paths you specify in your bootstrap loader files. The relative path of the yii2 directory and your application config file directories (and their associated applications via the config file paths) are specified in your bootstrap files under web/.
You actually have some control over where the parent directory containing the application directories is located if you choose to modify the template to meet hosting requirements. You can tweak the relative paths in the bootstrap loader files and do some trial-and-error testing to accommodate most hosts.
Thanks, and maybe my initial question was confusing.
Say I have xxx.com, yyy.com, and zzz.com all vhosted on a server. Each should have there own directory. Yii2 puts the framework in /vender OF EACH DIRECTORY. If I update the framework with a bug fix, I would have to update it in three different places, instead of just one. This also would need the space for 3 copies of the framework, amd for that matter what ever comes along with the install in /vender.
Well, space and performance isn’t really a factor. Disk space is dirt cheap and running multiple composer update commands will utilize composer’s cache. And if you’re using composer update --prefer-dist like you should be, then it’s even better.
So the only issue left is that you have to manually run these composer update commands for every project. However, this confuses me because you seem to only want to update Yii 2, but NOT the other packages?
You can extend your directory structure to have multiple apps on one install.
Another option - if your vendor directory is exactly same (by that I mean if you use exactly the same vendor packages across all 3 sites above)… you can use a simple symlink and run composer update only on one app.
For example:
xxx/vendor: The base vendor directory where you have all your vendor apps. Just run composer update here.
yyy/vendor -> symbolic link to xxx/vendor
zzz/vendor -> symbolic link to xxx/vendor
When I say update Yii2, yes I mean the other packages that come with Yii
@Kartik V The whole conversation was getting to the underlying reasons for forcing a multiple update, when good programming practice/OOP is to write once use a lot. Extsending the directory structure then puts, in this case, 3 different websites under one roof, with 3 different model structure, db connections, views, etc, etc, etc. Naming of tables/views would become a nightmare.
That’s generally true, but this is a different situation. There are two main issues when you’re talking about projects:
Different projects have different dependencies. One project may have some packages while another project will have other packages. This is a nightmare to manage if you try to get all your projects to "share" the same files.
Different projects may require different versions of the same packages. For example, if you update one project a lot but don’t touch another in a very long time. Updating a package then may completely break your second, third, fourth, etc projects unless you go in and check all of them.
@jkofsky as amnah mentioned you probably maybe mixing up two different issues. But you should be able to achieve what you want largely, if you can clearly articulate your app design needs:
How do you classify your projects? Is it end user/customer controlled? Irrespective of the code reuse - you may need multiple websites - for multiple customers/businesses. Based on this assessment, you may need to classify your various projects differently on your server.
You have one project but need multiple apps. You can create multiple app structure (like yii2-advanced) for a single project. That works by reusing code between backend and frontend apps from places like common, vendor etc.
Are your vendor package versions exactly same across all projects? Probably difficult to state this … but if so you can consider the hypothetical example I mentioned before of symlinking vendor folder.
You want a code reuse across projects / across installations. You may consider making it as an extension / module and reuse.
There are many other ways in which you can reuse code and work the OOP way (a topic of wider discussion).
Thanks for all your comments gang, I’m still having a problem wrapping my mind around the new paradigm. It seems weird to have a complete copy of the framework specific stuff in project site on the server. App/project specific dependencies, yeah they go in the project dir. I look at anything I write, or extension I download, they are project specific. The framework files I think of as a layer on top of php, and we don’t have a copy of php for every vhost site.