Better webroot structure (web/)

[swalkinshaw]

Bedrock currently exposes a lot of files to the webroot that shouldn't be there. The README provides some web server configs to block access to these files, but it's still not a proper solution.

This PR moves what's required into a web/ directory including the vendor'd WP source, and the app source itself. Now an Apache/Nginx site should be pointed to /path/to/site/web/ instead of just /path/to/site/

The name web was chosen since it reflects that its the webroot. public is a very common name in frameworks like Symfony, Rails, Laravel etc, but it doesn't directly map to our use case since that's always for static file serving like images, scripts, css etc.

See #10 for more discussion.

[lautreamont3]

    "installer-paths": {
      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
      "web/app/themes/{$name}/": ["type:wordpress-theme"]
    },

What about app/uploads not in web.

[swalkinshaw]

@lautreamont3 thanks, fixed!

[lautreamont3]

You did not change installer-paths in composer.json to web/app/....

[swalkinshaw]

@lautreamont3 wow only saw your comment about uploads... actually fixed now.

[lautreamont3]

I am not shure, because I constantly change my vagrant/apache configuration, but I don't think this is configuration error. So I think you need to add this #ADDITION to config/application.php:

$root_dir .= '/web'; #ADDITION 
define('CONTENT_DIR', '/app');
define('WP_CONTENT_DIR', $root_dir . CONTENT_DIR);
define('WP_CONTENT_URL', WP_HOME . CONTENT_DIR);

This will satisfy WP_CONTENT_DIR and ABSPATH but not WP_CONTENT_URL (change of CONTENT_DIR to /web/app will influence both _DIR and _URL, I am kinda arguing with muself).

BECAUSE YOU ONLY READ END OF MESSAGES I SPLIT THIS TO POINT SEPARATE TEXTS

I have one question my configuration don't work if I leave

require_once('../vendor/autoload.php');

in web/wp-config.php, I must use absolute path or I get error

PHP Fatal error:  require_once(): Failed opening required '../vendor/autoload.php'

am I doing something wrong?

[rslnk]

I came across the same issues with WP_CONTENT_URL and require_once('../vendor/autoload.php'); while trying to incorporate this PR in my Bedrock configuration.

To solve the first issue with WP_CONTENT_URL, I've added a new CONTENT_ROOT variable:

define('CONTENT_ROOT', '/web');
define('CONTENT_DIR', '/app');
define('WP_CONTENT_DIR', $root_dir . CONTENT_ROOT . CONTENT_DIR);
define('WP_CONTENT_URL', WP_HOME . CONTENT_DIR);

As for the require_once('../vendor/autoload.php'); giving an error, my guess is that this has something to do with require_once function working relative to the path of the wp-config.php file from where it is called.

Adding the full file path to the wp-config.php seems to work:

require_once (__DIR__ . '/../vendor/autoload.php');
require_once(__DIR__ . '/../config/application.php');

Note: __DIR__ constant will work with php 5.3+

Both workarounds worked for me, however, I'm not sure if that would be the most elegant solution. Even though I've developed my first WordPress website by being inspired by the Roots theme a few years ago, I'm still only a beginner to the whole new concept of Modern Wordpress Development Workflow.

[swalkinshaw]

Sorry guys, I've just been doing this PR manually without testing it (not a good idea btw). Just opened the PR a bit early, but you're both right.

@rslnk there's nothing wrong with your solution. Requiring absolute vs relative paths isn't really less elegant. Probably better in the long run and using __DIR__ is completely fine since to use Composer you need > 5.3 anyway so anything Bedrock does can (and should) take advantage of 5.3 features like namespaces too.

[lautreamont3]

No problemo, with this changes everything works like standard Bedrock.

@rslnk Dont forget ABSPATH.

[swalkinshaw]

@rslnk squashed all your commits into 1 but all the work is still there :)

[lautreamont3]

Correct .gitignore

# WordPress
wp
.htaccess

to

# WordPress
web/wp
web/.htaccess

[francescolaffi]

I would rename APP_ROOT to WEB_ROOT to avoid confusion with the content dir that is named app, also as said in the pull request description its commonly referred as webroot; maybe also move this constant up near $root_dir definition since this section is about custom content dir, just my 2 cents ;)

anyway good PR 👍

[swalkinshaw]

Good suggestion. Just did those changes since they makes sense.

[4selected]

What's the best to way to have "htdocs" instead of "web" dir? Do I have to fork your repo and modify it on my own?

[retlehs]

yep.

[4selected]

Wow, that's fast. do you think it's good to update the README with the new web path for my fork? And leave you and Scott as authors in the composer file? Sorry for this questions, but I'm new to this :/

[etcook]

You could also use a symlink for htdocs to the web directory if that option is avail to you.

[swalkinshaw]

@studio4s I probably wouldn't worry about updating anything else. Not really important in the long run.

[swalkinshaw]

Running composer create-project studio4s/bedrock studio-test picks up the latest tag which Packagist syncs from GitHub if you setup that hook. Since you haven't tagged a new releases, it's taking the last one which is just normal Roots. You can get around it by running:

composer create-project studio4s/bedrock studio-test dev-master

Specifying dev-master will get the latest version from the master branch.

[4selected]

@swalkinshaw that you so much Scott!!!