Bedrock is a modern WordPress stack that helps you get started with the best development tools and project structure.

There's a few features of Bedrock that might make some Multisite setups a problem:

• WP installed in subdirectory
• Custom content folder

Looking at some issues regarding this, it seems like MS support is still a bit of a mess. Related issues:

• https://core.trac.wordpress.org/ticket/27287
• https://core.trac.wordpress.org/ticket/23221
• https://core.trac.wordpress.org/ticket/26969

Here's a potential mu-plugin we may want to consider adding in Bedrock by default: https://gist.github.com/danielbachhuber/9379135

/cc @ddebernardy I'm hoping you can speak to/summarize some of the issues you've ran into and potential solutions.

There is a problem with language support (again). In this setup seting WPLANG to something does not do the trick because WP does not expect language directory in wp/wp-content but in app. If I wanted to work, I must move directory manually after composer install and before wordpress installation. Is there a way to tell composer to do this. For some reason themes works from wp/wp-content but language not.

Hi,

The current Bedrock setup is not ideal for shared hosting environments or hosting environments with a control panel like Direct Admin. Changing the vhost to point to the /web directory is not always possible, allowed or the best option. Maybe it's an idea to ship a .htaccess file with Bedrock with some rewrites like suggested here: https://discourse.roots.io/t/ftp-use-and-point-domain-to-web-folder-w-htaccess/1556 to make Bedrock more "compatible". But with some extra security like:

RewriteRule .env - [F]

OR

Order Deny,Allow
deny from all

<Files web/*>
    allow from all
</Files>

Maybe we can debate here for the best .htaccess setup?

I know there were recently two applicable discussions: https://github.com/roots/bedrock/issues/38 and https://github.com/roots/bedrock-ansible/issues/34 ... but after reading them I am still left with some questions.

It seems like the "recommended" way is to use Batcache + Memcached. Okay, great... but is Batcache still supported? It had no update in >7 months and the version on WordPress.org has not been updated for 2 years. Even if it is still maintained and works, it looks like you still need to have advanced-cache.php in the wp-content/ (or app/) directory. But since this is configuration, we should not be linking it via shared? So how do I manage it for deployment?

On top of that, I mostly run single sites on single servers. Or maybe a couple vhosts on a server. Memcached is not really for this situation and Batcache even recommends using WP Super Cache in that case. I like WP Super Cache and am familiar with it but am running into the same issue with advanced-cache.php and the cache/ directory it creates. I don't mind blowing up the cache on deploy, and I suppose I could also link cache/ to shared/ as is done with uploads/... but I'm still not sure if that is "right" and am still left with advanced-cache.php sitting in app/. On top of that, Batcache instructions on github are less than clear... i.e. what the hell is Ryan's Memcached Backend 2.0, what does it do and why do I need it? I know that is a Batcache thing and not Bedrock, but no one seems to be home over there anyway.

I am only just dipping my toes into Bedrock to see if it will work for our organization and so far I love it, but I am little surprised that more focus has not been put on the issue of caching since it is pretty vital to any WP site that generates even moderate traffic. I just want to try and get some input on the "best practices" approach because if I need to start deviating too far from the norm than there is really no purpose for me to continue with Bedrock.

Based on this article about completely disabling automatic and/or UI-driven updates in WP (which is what we want in Bedrock AFAIK) and on my own experiments:

DISALLOW_FILE_MODS implicitly includes AUTOMATIC_UPDATER_DISABLED and DISALLOW_FILE_EDIT, plus:

• It hides the update notifications in the admin bar.
• It hides the "Updates" sub-menu in the "Dashboard" admin menu.
• It hides the "Update Available" messages in "Appearance -> Themes" and "Plugins -> Installed Plugins".

I verified in the WP source that DISALLOW_FILE_MODS actually includes AUTOMATIC_UPDATER_DISABLED and DISALLOW_FILE_EDIT, and it is confirmed respectively here and here.

The first plugin often installed in many Wordpress setups is W3 Total Cache.

This plugin creates app/cache/ and app/w3tc-config/ directories outside of the app/plugins/ directory in addition to three other files used by the plugin: advanced-cache.php, db.php, and object-cache.php.

Perhaps adding plugin-specific ignores to Bedrock is a bit much, but maybe a line about this is the readme would be a good idea?

From README.md:

plugins, and mu-plugins are Git ignored by default since Composer manages them

As of now, it seems to suggest that all plugins will be placed into the /app/plugins/ directory and be contained there, kept in check via Composer without any additional configuration of Bedrock's files.

I have recently set up my first multisite with Bedrock, and I have encountered several issues where the URLs are not correct. After some investigation, I figured that the issues are a result of a problem in WordPress Core - in some places it does not honor the site URL setting. This is no problem with a regular WP install, but when WordPress is installed in a subdirectory as it is in Bedrock, the site URL is different from the home URL.

The most significant problem is that some areas in the network admin will direct me to /wp-admin instead of /wp/wp-admin, for example when you're on the My Sites section and click on "Edit Site".

To be clear, this is not a Bedrock bug, but I think it would be great if Bedrock provided a fix for it, so that other people do not run into this problem. While there are ways to workaround this with nginx / htaccess rewrites, I'd prefer to actually fix it from the code site. As of now, I have fixed these issues on my site, so I'll create a pull-request with my approach.

Btw I also created a ticket on Core Trac, the first responses told me that WP doesn't officially support this - so not sure whether there will be a Core fix soon.

$ cap production deploy
 INFO [e9cd1232] Running /usr/bin/env mkdir -p /tmp/my_app/ on my_app.com
 INFO [e9cd1232] Finished in 0.484 seconds with exit status 0 (successful).
 INFO Uploading /tmp/my_app/git-ssh.sh 100.0%
 INFO [e91dcfcd] Running /usr/bin/env chmod +x /tmp/my_app/git-ssh.sh on my_app.com
 INFO [e91dcfcd] Finished in 0.063 seconds with exit status 0 (successful).

This all looks good, but it doesn't create the directories or anything.

• [x] tag roots/wp-config 1.0.0 before merge

Problem

The current Bedrock configuration system does not strictly adhere to one of the most important Roots core values:

All environments should match production as close as possible.

Stated another way and scoped specifically for Bedrock:

Environment configuration values should default to production values and only deviate if absolutely necessary.

This is not how bedrock currently works. the current bedrock configuration process described by the docs in general works like so:

Which seems fine at first. However, upon further examination it falls apart.

The docs describe this intended usage:

The environment configs are required before the main application config so anything in an environment config takes precedence over application.

Note: You can't re-define constants in PHP. So if you have a base setting in application.php and want to override it in production.php for example, you have a few options:

• Remove the base option and be sure to define it in every environment it's needed
• Only define the constant in application.php if it isn't already defined.

At best the config process:

1. is not DRY
2. does not fail safe in situations of an unexpected WP_ENV value.
3. will silently reject configuration values if a user is not clear on how define()ing constants in php works
4. is not consistent with our environment parity recommendations

Not DRY

If you want all environments to match production you would have to copy paste the contents of environments/production.php to everywhere except environments/development.php. Obvious DRY violations aside, this is error prone. environments/staging.php can easily get out of sync with environments/production.php and congratulations your staging environment no longer reflects production or vice versa.

Does Not Fail Safe

You could perhaps require_once __dir__ . '/production.php'; in every file except development.php. However now the second Bedrock encounters an unexpected WP_ENV variable (staging-experimental, productoin, or undefined to name a few): Bedrock will fail open and stuff like WP_DEBUG_DISPLAY will default to true (!!!). No web framework should behave this way when undefined values make their way into the system.

Silent Configuration Rejections

In ruby

irb(main):001:0> WP_DEBUG_DISPLAY = true
=> true
irb(main):002:0> WP_DEBUG_DISPLAY = false
(irb):2: warning: already initialized constant WP_DEBUG_DISPLAY
(irb):1: warning: previous definition of WP_DEBUG_DISPLAY was here
=> false

Clearly I am trying to do something bad and the logs will reflect this.

In PHP

php > define('WP_DEBUG_DISPLAY', true);
php > define('WP_DEBUG_DISPLAY', false);
php > var_dump(WP_DEBUG_DISPLAY);
bool(true)

Yikes.

Not Consistent With Roots Recommendations

If we recommend:

All environments should match production as close as possible.

Then why does a user have to take explicit action to make this happen for every environment they define? Why doesn't it just default to this behavior? In the current model production configuration is "opt-in" instead of "opt-out". This is perpendicular to what we recommend.

Solution

"Production" configuration should be specified in its entirety in config/application.php and files in config/environments/*.php should only be used to override production behavior. For instance in development.php you would want to show error messages and define debug flags and stuff.

To do this we should

1. Collect all the configuration values in application.php as key value pairs in a map
2. Collect all the configuration values in the desired config/environments/WP_ENV.php file and merge them with the key value pairs collected in application.php
3. After all configuration values are collected we should apply them to the environment via define()

At every point in every step above we need to protect the users from redefining constants.

Implementation

NOTE: Before your eyes glaze over looking at crazy UML diagrams: go read the code. What we are doing here is very simple and takes less than 100 lines of code.

Lines of Code (LOC)                              127
Comment Lines of Code (CLOC)                      56 (44.09%)
Non-Comment Lines of Code (NCLOC)                 71 (55.91%)

The reason I am going so overboard with explaining the implementation is because I need a second pair of eyes to sign off on the UX I am proposing here. I want to validation on if throwing these exceptions in these places makes sense etc. Also in writing this explanation I have already fixed a couple edgecases.

I have defined these classes:

Who's usage looks like:

To produce:

Exceptions

I throw a ConstantAlreadyDefinedException when a user attempts to enter a situation described in the "Problem" section where PHP would silently reject the configuration value.

I throw a UndefinedConfigKeyException when a user attempts to fetch a value with Config::get(k) that doesn't exist in Config::$configMap. I do this because the control flow is nice and return null is not working because null is a viable configuration value. We don't use Config::get(k) anywhere but it is a part of the API because I can see users needing it.

Backwards Compatibility

All of this Config class madness is opt-in. Nothing stops a user from just going back to using define(). Config::define() is just an alternative API that behaves in a safe and sane way with regards to overriding environment configurations.

Conclusion

I am out of time for today so can't elaborate much further. Interested to discuss this with you guys!

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.

• [X] I've read the guidelines for Contributing to Roots Projects
• [X] This request isn't a duplicate of an existing issue
• [X] I've read the docs and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

I have recently updated composer and got the oscarotero/env v2.1.0 package. Since then I keep getting this error:

Fatal error: Uncaught Error: Class 'Env' not found in /myproject/config/application.php:6

Steps to reproduce

1. Update composer to v2.1.0 on package oscarotero/env
2. Check your local repository

Expected behavior: [What you expect to happen]

Expected to run site normally.

Actual behavior: [What actually happens]

Throws error Fatal error: Uncaught Error: Class 'Env' not found in /myproject/config/application.php:6

Reproduces how often: [What percentage of the time does it reproduce?]

100%

Versions

oscarotero/env v2.1.0

Additional information

This is the content of the referenced file, where Env::init() corresponds to line 6:

<?php

$root_dir = dirname(__DIR__);
$webroot_dir = $root_dir . '/public';

Env::init();

// Use Dotenv to set required environment variables and load .env file in root
$dotenv = new Dotenv\Dotenv($root_dir);
if (file_exists($root_dir . '/.env')) {
    $dotenv->load();
    try {
      $dotenv->required('DATABASE_URL')->notEmpty();
    } catch (Exception $e) {
      $dotenv->required(['DB_NAME', 'DB_USER', 'DB_PASSWORD', 'WP_HOME', 'WP_SITEURL']);
    }
}

It seems as if the package were not loaded since the Env Class doesn't load. Ideas?

https://www.php.net/supported-versions.php https://endoflife.date/php

I'd prefer to bump this to PHP 8.1, considering active support for PHP 8.0 ended on 2022-11-26, but WordPress & WP-CLI still don't fully support it at this time

Ref https://roots.io/wordpress-php-8-1-support-not-found/ Ref https://core.trac.wordpress.org/ticket/54504 (coming in WordPress 6.2) Ref https://github.com/wp-cli/wp-cli/issues/5623

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Summary

config/application.php looks for .env assuming only one such file exist (and consequently one database can be connected to that bedrock installation).

Several scenario require more flexible .env choosing. In my team, I replace the loader by:

$prefix = explode('.', $_SERVER['HTTP_HOST'] ?? '')[0] ?? '';
$dotenv = Dotenv\Dotenv::createUnsafeImmutable($root_dir, ['.env.' . $prefix, '.env']);

So that locally, our various projects can be access using a subdomain, eg: site1.localhost.dev would load .env.site1. Today I found that it was a neat way to get WordPress network up and running in -production while still having one database per instance (something not supported by WP), eg:

$dotenv = Dotenv\Dotenv::createUnsafeImmutable($root_dir, ['.env.' .$_SERVER['HTTP_HOST'] ?? '',  '.env']);
// Loads `.env.example.org / .env.example2.com` according to the hostname.

It works well but I'd prefer to do that without modifying Bedrock core files. Any chance to get a hook or similar that would allow to customize the .env selection inside a 3rd-party file?

Motivation

Why are we doing this?

To support multiple database per Bedrock installation

What use cases does it support?

Local development, improved WP network setup

What is the expected outcome?

More flexible multi-db setups

Potential conflicts / foreseeable issues

None

Additional Context

No response

This PR contains the following updates:

| Package | Type | Update | Change | |---|---|---|---| | actions/checkout | action | major | v2 -> v3 |

Release Notes

Configuration

📅 Schedule: Branch creation - "before 3am on Monday" in timezone America/Chicago, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

This PR contains the following updates:

| Package | Type | Update | Change | |---|---|---|---| | actions/cache | action | major | v2 -> v3 |

Release Notes

Configuration

📅 Schedule: Branch creation - "before 3am on Monday" in timezone America/Chicago, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• [ ] chore(deps): ⬆️ bump actions/cache action to v3
• [ ] chore(deps): ⬆️ bump actions/checkout action to v3

Detected dependencies

• [ ] Check this box to trigger a request for Renovate to run again on this repository

This feature is based on #540 and partially resolves #522 but instead of removing the "Background updates" test, this plugin alters its status, label, and description, to explain why its disabled.