Public folder

[ravage84]

Hi @pmjones

Thank you for your research and work on this.

Personally, I'm a big proponent of such a minimalistic standard. I contributed to thephpleague/skeleton in the past and even setup a small skeleton for CakePHP 2.x Plugins.

Since I support such an endeavor, I had a discussion about your standard with my team. They all support it, though it became clear, that the public folder was the only one that is kind of controversional.

While I guess almost all of your proposed folders and files are already nearly de-facto standards or could become a standard without much of a fuzz, the public folder is the one where many devs will have a diverging opinon about.

This could be because their framework simply demands them to put their public html stuff in a differently named folder or simply because of long time habits.

Anyway, it would be really sad, if people can't adopt the standard, because they cannot adhere to your public folder requirement.

And the way, how the draft is worded right now, it is a requirement:

https://github.com/php-pds/skeleton#public

If the package provides a directory for web server files, it MUST be named public/.

That's why I really recommend you to not include the public folder with a MUST but wit a RECOMMENDED wording.

This way, your standard gets adoption very easily.

And if the PHP community settles on this matter in a nearby future, you can include the plugin folder with a MUST in a later version of the stardard.

It's way easier to evolve a standard over time than trying to revolutionize with it.

[pmjones]

the public folder was the only one that is kind of controversional ... It's way easier to evolve a standard over time than trying to revolutionize with it.

I agree on both counts. Hell, I use the name web/ in my own work, so this would mean a change for me as well.

Unfortunately, the only other name supported by the research is assets/ (the highest frequency at 2.958%, vs public/ at a very close second place 2.902%).

[ravage84]

Again, I see you focus very hard on your research. Which I totally understand.

But it feels like it becomes a "take it or leave it" approach, based on "because research told us so". Yes, your research based on raw data totally resulted in that conclusion.

But couldn't be a refinement on that be: "Hey, this could be and probably is controversional, so we probably should not claim it a standard?"

[ravage84]

A standadr is a very strong word and has quite some meaning. And it's very good to base something like that on research (kudos for that approach!).

But claiming something controversial to be a standard ,because pure numbers say so? Dangerous in my opinion...

[Revisor]

Ravage, do you agree with public but would just change MUST to SHOULD? Or do you propose something else altogether?

I took a look at what the biggest frameworks use as a default directory:

• Symfony: web
• Laravel: public
• Yii: www
• Phalcon: public
• Zend: public
• Nette: www
• CakePHP: webroot

[ravage84]

Personally, I would just reword it toRECOMMEND or SHOULD. Takes away much of the controversy...

[odan]

This standard is very good because it finally creates clarity. If you say SHOULD you only create new controversy, which is not the aim of a standard.

PS: I prefer: public/

[casimiroarruda]

My 5 cents: Thinking on semantics: public or www could lead to mistakes(e.g APIs could not be "public" or not used on "www"). Personally I use web. webroot would be most meaningful name to this. Suggesting other names is useless as we have no reference to it.

Agreed with @ravage84 on change the rule to RECOMMEND or SHOULD but I still prefer a directory name "free" (or almost) of misconceptions for the sample.

[pmjones]

Sorry, all, but I think public/ has the strongest position here.