[STICKY / IMPROVEMENT] Corrected relative paths

[graulund]

I'm using Huge as a part of a larger setup, and in my setup, these relative path includes did not work for me — they're relative to the including file, not the included file. I fixed the file paths to be relative to the included file, and thus work no matter what the setup.

[panique]

Sorry but this breaks the project :/

Currently there's an auto-installer etc. that will setup everything it will run fine. So I think you are running an own config / apache/nginx setup somehow ? Can you please go into detail what's different in your setup compared to the one from autoinstaller ? Thanks! :)

[graulund]

Oh — Can you elaborate on how exactly it breaks the project? I'll try to fix that.

The point of the commit is that PHP resolves relative paths relative to the entry file, even within included files, which is why you in your include paths have to write ../application/config/ in a file that's in the application/core folder, which doesn't make sense, because there's no application/application/config folder.

It works because the entry point in your demo project is in the public folder, whereas in my own setup, I have the entry point in the root folder, and then it doesn't work because of some hard coded string deep in the project, which is a little bit unfortunate. It prevents flexibility in the project setup.

I'm not trying to undo your settings, I'm only trying to make it more flexible, so the entry point can be anywhere. Using the __DIR__ magic constant makes it work because it's always the value of the directory of the included file, not the entry file. :)

[panique]

He @graulund , thats the thing, in HUGE the entry point in always the index.php inside /public folder, which is the recommended way in web applications, so everything that should not be public is really not public. If I understand you correctly, then you've changed that behaviour and moved the index.php, which is a deep change, so please don't get me wrong here, but changing something such essential in your personal installation does not really "justify" a total change of the projects logic! The current logic makes PSR4 possible, makes it work on nginx/apache without lots of configs and it works perfectly even when inside a subfolder, and there have been thousands of installations that run fine, also this project has reached end of life a year ago (so no code changes anymore), in the end I would totally recommend to leave the project like it is, as my experience is that deeper logic changes will make problems when not tested properly. I totally think that your solution is actually the better one, but touching this end-of-life project again for such a change ... hmm, might be too risky compared to the actual result.

Thanks for the commit, I think it would be cool to simply leave this ticket always open so people might find this solution for their own projects!

[graulund]

Alright, that's a totally fair decision. As long as you know that this code would totally work fine with the default case (index.php in the public folder). It wouldn't break anything.

[panique]

TODO