Update usage examples in the documentation: make a subdir the web root

[dnaber-de]

The current documentation shows a quick start and a complete example. Both show, how to configure WP-Starter to be the web root directory which exposes the .env file to the public.

It's easily possible to set up a structure like this, where the public/ directory is considered to be the web root:

public/
    wp/
    wp-content/
vendor/
composer.json
.env
.gitignore

I'm preparing a PR on that…

[dnaber-de]

In https://wecodemore.github.io/wpstarter/docs/complete-example.html the example composer.json contains this:

"config": {
    "vendor-dir": "public/content/vendor",
}

The only reason that requires the vendor directory to be public would be that we consider packages shipping assets like JavaScript and CSS files. I don't know of any package (of type library) that ships with assets and if so, I would name this a bad practice. Assets should only be shipped in «higher order» package types like wordpress-plugin. Therefore my suggestion would be to remove the custom vendor-dir setting completely from the example. This would also simplify the documentation as it is nothing related to WP Starter. What do you think, @Giuseppe-Mazzapica @franz-josef-kaiser ?

[gmazzap]

The current documentation shows a quick start and a complete example. Both show, how to configure WP-Starter to be the web root directory which exposes the .env file to the public.

Actually the "complete example" did used the "public" folder for WordPress and content, to avoid expose .env to public folder, in fact it contains:

"extra": {
        "wordpress-install-dir": "public/wp",
        "wordpress-content-dir": "public/content"
}

but I'm agree it should also be made more explicit (plain explained) and also be part of "quick start example".

The only reason that requires the vendor directory to be public would be that we consider packages shipping assets like JavaScript and CSS files...

Agree again. Main reason behind this is my lazyness: when I wrote that one I copied most of the composer.json from http://composer.rarst.net/recipe/site-stack that contains that.

I think we can avoid that one. Maybe in the future we could add a "recipes" section with specific solution to specifc problems, like giving web access to /vendor.

At this point, if @franz-josef-kaiser has nothing against we can proceed forward updating documentation.

To avoid duplicating effort, @dnaber-de can you take care of this?

If so, please assign the issue to yourself and do the change whenever you can.

If not, please let me know, I'll do it as soon as I can, probably when back from WCEU.

[dnaber-de]

@Giuseppe-Mazzapica @franz-josef-kaiser I already worked on that, as you might see from the linked commits. I'll check my update against your comment and provide a PR soon.

@franz-josef-kaiser You can assign me to the issue, if necessary.

[gmazzap]

Documents are updated in the "complete example" and below the "quick start" example there's a clear explaination of the security issue that is having .env publicly accessible. So this can be closed. Thanks!