Change order of autoload file import

[raissanorth]

This will ensure the autoload file is first searched for within the project itself, rather than outside of it.

[dhensby]

This is a revert of #19 and I'm not sure I see the logic in making it.

As it stands (before this PR) is that the first location is not "outside the project" it's the project folder, the second location checked is the public folder (which is basically fallback logic in case you moved your index out of public and into the project root).

Especially in master, where we're going to mandate the public folder, I think this change makes little sense and we should really just remove the check in the current directory.

[dhensby]

as per feedback

[tractorcow]

In 5.x we want to make public mandatory; Then we should ONLY check '/../vendor/autoload.php'.

[tractorcow]

Looking at the code it doesn't seem we've enforced public dir yet.

[robbieaverill]

For context here:

• composer create-project cwp/cwp-recipe-core ./cwp2-core 2.1.x-dev (includes recipe-core 1.2.x-ev)
• no public web root is created
• the first autoload call looks up a level from the project web root

In this case the folder above the project had had compose require foo run in it (mistake, but it happens and often doesn't become obvious), so had its own autoloader, and this order of logic was loading that autoloader rather than the one in the project. This lead to quite an annoying amount of head scratching and repeated cache flushing to work out why classes couldn't be found.

Side note: CWP 2 enforces the public webroot but it doesn't look like the cwp/cwp-recipe-core recipe does on its own. It should (I'll log a separate issue for this -> silverstripe/cwp-recipe-core#10).

[tractorcow]

Ok suggested this at silverstripe/silverstripe-framework#8168

[tractorcow]

@robbieaverill because it's opt-in for framework 4.x you need to physically add the public folder to the git repo for cwp-recipe-core.

[tractorcow]

@robbieaverill we can fix the issue by checking that basename(__DIR__) === 'public' as an added precaution.

[robbieaverill]

Right - public isn't a configurable name at the moment is it?

[tractorcow]

Correct. You can only have it or not have it.

I've already vehemently vetod the ability to soft-code the name of the folder. We hard-code it in many places, including composer plugins, which don't have the ability to read silverstripe config.