6.0 at the very earliest.

There is no 6.0 branch yet, so he has to open it for 5.

6.0 at the very earliest.

Sure, but can the maintainers agree on:

• the name of the folder This is customisable now
• consider including the changes of the HTMLHelper + WAM in 5.0 to ease the path forward

There is no 6.0 branch yet, so he has to open it for 5.

Then the title should at least be changed to say 6.0 and not 5.0

What I am missing here is an explanation of

• the benefits of this change
• what happens to existing sites

Then the title should at least be changed to say 6.0 and not 5.0

@brianteeman the public folder maybe could be delayed till 6 but IMHO it will be a good pointer if the changes in the WAM and HTMLHelper are done in the 5.0

the benefits of this change

Security, if you know you know...

what happens to existing sites

Nothing is changed. The idea is that this would be an option at the end of the installation where the user could choose if they will opt in to a safer env or not (for some hosts there might not be an option to select a subfolder as the actual served folder).
Also, I guess the change could be provided through the com admin or config (it's just creating a public folder with some files, few symlinks and copying the .httaccess)...

I thought that might be the reasons claimed for this change although this implementation does not achive it. It has been discussed many times before and while it is a possible option with hosting that you have full control of it is not possible at all with typical shared hosting. For that reason I am not in favour of this at all and it really cannot be tested on a local environment in the way you described

I like the idea but not sure about the implementation.
Also I would to see a .htaccess protection ruleset for all files first or as alternative.

For example I don't like that the public folder must be a subfolder of jpath_root

I like the idea but not sure about the implementation.

This IS NOT A PROPOSED IMPLEMENTATION!!! I just made the minimum viable testable version here to showcase that the actual needed changes (apart the public folder shenanigans) are less than 20locs (the HTMLHelper and the WAM files, the first 2 on the files list)

Also I would to see a .htaccess protection ruleset for all files first or as alternative.

I cannot help here, I'm using NGINX

For example I don't like that the public folder must be a subfolder of jpath_root

I guess it's doable to have them in completely different trees but then you have to define the paths according to the parent root folder. FWIW all the PHP projects that I'm aware (Laravel, Symphony, etc) are using a subfolder (usually public, thus I also used it here) similar to this example

it really cannot be tested on a local environment in the way you described

testing instructions updated

@HLeithner now if someone defines correctly both JPATH_PUBLIC and JPATH_PUBLICNAME it's possible to have the public folder:

• named whatever they want
• not a direct child of the JPATH_ROOT

if possible I would remove the complexity by assuming that your new constants are always defined.

if possible I would remove the complexity by assuming that your new constants are always defined.

If I didn't messed up the constants are now defined also on the root, administrator, api defines.php. Someone should double check that this is ok, as these files could be overridden by design

@HLeithner let me know if this is something that could be considered for 5.0 so I don't waste my time here. Thanks!

if you write this was a bad idea, it would be really useful to write why it was a bad idea

if you write this was a bad idea, it would be really useful to write why it was a bad idea

So, I thought that having the static html pages (build_incomplete, incomplete) available directly in the includes folder would simplify things and then I checked that PHP is doing a file read. Also the changes here are tweaked to reflect an easy path to actually achieve a public folder (either though CLI or GUI) base on the code from https://github.com/dgrammatiko/public-module/blob/main/src/modules/administrator/publicfolder/src/Helper/PublicfolderHelper.php

BTW this PR should be ready for testing (ie install J from this PR and the module from the other repo and try both the nested public folder and a public_folder not a direct child of the J root)

I think having this is a good idea overall - especially given our reliance on the composer folder which we've increasingly had to blank out in htaccess rules i suspect many people on shared hosting don't enable anyhow). I don't think it's anything we want to expose though through the UI. I can imagine us using it in our own docker images and documenting for those who want to use it. The impact to extension devs and users is going to be nearly non-existent.

Worth noting this probably would only work on extensions who use the new parent template options (and therefore store their css/js/images in the media directory as opposed to the templates directory.

I don't think it's anything we want to expose though through the UI.

Although I created a module that would create the symlinks and all the other shenanigans I wouldn't suggest that for the core! That said and since there's a CLI installer for Joomla a couple extra params could expose a way to install Joomla directly with a public folder. The CLI version also, by default, is targeting advanced users so it should align nicely with what George wrote above.

Worth noting this probably would only work on extensions who use the new parent template options

Yup, I've mentioned that in the description: Gotcha: legacy templates WON'T work with this!!!

thanks, please write some documentation at manual.joomla.org

Oh wow, this is a great leap forward for security! Thanks