PSR-4 compatible plugins

[ericp-mrel]

I was wondering if there was a reason why all of Winter CMS is not PSR-4 compatible, including plugins. It seems like everything must be lowercase, otherwise it will not work.

I think it would be nice if everything could be PSR-4 compatible to match the rest of Laravel.

I was just wondering if there would be any interest in wanting this, because for me personally it can be kind of annoying when creating new classes and stuff in Phpstorm and constantly having to correct it with the appropriate path and namespace since it keeps trying to use PSR-4, but Winter CMS doesn't work with PSR-4. Especially because the README states the project uses PSR-4 coding standards.

[LukeTowers]

Anything specific you're talking about? I'm not really sure what the problem is, I've never run into issues with namespace casing before.

[ericp-mrel]

I'm going to use this plugin as an example: https://github.com/ericp-mrel/wn-test-plugin/tree/psr4

One example, if I rename the controllers folder name to be capitalized (Controllers) then I get a 404 in the backend. It seems like there are places throughout the code which converts paths into lowercase https://github.com/wintercms/winter/blob/develop/modules/backend/classes/Controller.php#L144
So, even if this controller worked and didn't 404, it wouldn't be able to load the layouts because of case-sensitive file-system on Linux.

EDIT:
Maybe that specific line wasn't the greatest example. Here's a better example of where strtolower is being used which prevents the controllers from truly being PSR-4 compatible: https://github.com/wintercms/winter/blob/develop/modules/backend/classes/BackendController.php#L267

[LukeTowers]

Gotcha, I see what you're saying. As far as I'm aware there's nothing specifically blocking it from working (the line you submitted is merely to add support for the case insensitive approach for loading classes, not to block uppercase usage). It's just generally the convention within Winter to always use lowercase folder names; probably to avoid issues with case sensitive file systems.

[bennothommo]

While I suppose it's correct in that Winter's modules and plugins do not follow PSR-4 completely, the library does at least. I'm not sure we can introduce a hard requirement for PSR-4 given that it would make most plugins incompatible, but we could perhaps look to making it so that if people opt for PSR-4 pathing in their plugins, it should work.

Modules and plugins are chiefly loaded through the Winter\Storm\Support\ClassLoader class - specifically, these two lines dictate the possible paths for classes.

[ericp-mrel]

Yeah, I figured it wouldn't be feasible to require a change to PSR-4 for plugins and stuff. But it would be nice to be able to have the option of making plugins PSR-4 compatible, at least I personally and not sure if it would be desired enough to bother adding support for it.

[LukeTowers]

At the very least we should clearly document this diversion from PSR-4 in our developer guidelines / other documentation as applicable.

[Flynsarmy]

I'm thinking diverging from standards might put a bad taste in developers mouths. I'd suggest making PSR-4 work completely and deprecating the old way of doing things (if that's possible). I understand the need for backwards compatibility with October but at this point Winter is still very young, its marketplace isn't up yet and the developers of pretty much all plugins built for Winter are still around (if they're not, the plugins can always be forked and fixed).

This problem will only get worse with time - it should be taken care of now, not later.

[bennothommo]

We can't really deprecate the old paths, but @LukeTowers is working on a PR to allow proper PSR-4 paths to be read and used too.

Eventually then, we can phase out the old paths in our first-party plugins.