I just had a quick question… the file system structure in Yii2 seems off to me… is there a reason that with the rewrite some type of standardized cascading file system has not been created?
For example, the file location:
vendor/yiisoft/yii2-dev/framework/yii/
seems insane to me…
Is there some type of writeup or conversation that explains the method behind the madness?
Composer knows where to find framework files and takes care of updates.
Autoloader knows where to find classes. There’s no need to include anything manually.
Your IDE knows the location of classes and probably has a "Go to definition" or similar function for quick access.
I can’t see any problem with long filesystem paths.
As a first suggestion for a new Yii2 user, apparently, the vendor folders are something you MUST NOT be typically manipulating manually - since you will be using composer (which has inbuilt support with yii-2).
Yii Framework 2.0 uses the composer package manager (enhanced for yii) which automatically manages package and extension dependencies, and installs or upgrades stuff into the vendor folders. This is a major change for you if you are coming over from Yii 1.x, where you had to individually download third party packages/extensions and maintain them and their version dependencies manually.
You may want to read more about composer separately on the web and how it is a popular PHP dependency manager. The Yii2 Guide documentation for Composer should also be very handy.
Thanks guys,
I understand how composer works and everything… it just seems weird to me that it isn’t more readable, that’s all.
(Saying “You shouldn’t touch it so it can be like that” seems kinda ‘ASP.NET-y’ to me 
)
As an example, I want to override a view from a module that is in the vendor directory… but I literally have absolutely no idea how to override it because the filesystem structure is not clear from just looking at it 
With composer any overriding you do in the vendor folders… is overwritten when you do a composer update. So you basically lose the dependency management advantage of composer. There is nothing ASP about this… because you may still be able to achieve what you want by extending the classes in the vendor directory.
It also depends on the quality of the extension developed - it should allow proper parametrization for developers to customize/extend it easily.
As I said, it depends on how the module or extension has been coded, and how it can be configured. If I were doing the extension, I would have given the user the choice to setup most of these as configuration settings - if needed.
Since you mention a view in the module, you may still try by extending the Classes which call the view or the Controller within the module with something like below:
For example:
use module\VendorController;
class CustomController extends module\VendorController {
public function actionIndex() {
$data = parent::actionIndex();
$params = ... // do the coding needed
return $this->render('customview', $params);
}
}
[font="Trebuchet MS"]NOTE: You can still do everything the Yii 1.x way by manually copying the vendor files to your app/modules folder… and setting up everything OR CHANGING whatever you want manually. You do not need any composer to do this. You can even change the code you want. But then be prepared to have a system where you cannot manage packages as they get upgraded. You are totally losing out on all dependency management of packages by composer… which is one of the major differences between Yii 2.0 and Yii 1.0.[/font]
Hehe 
It depends …
The supercool thing now is, that all your 3rd party code in vendor/ is in a repository now.
Usually it "should" not be needed to change things there, but if you find a bug or add a feature you can instantly create a PR from your current project. Just fork the repo on github and push directly into your fork. Then create a PR from there.
I haven’t tried this in Yii2 yet, but even in Yii1 that was a fairly easy task.
Take the yii-user module for example. It has a login screen handled by its UserController.
[size=2]So you need to create a theme, eg. "default" and then put a custom login view under path/to/themes/default/user/user/login.[/size]
[size=2]
[/size]
[size=2]I bet it’s even easier with the new view object.[/size]