Do you use Bedrock on production servers or do you convert it to regular WordPress on deploy?
We just launched an update to our website and we’ve converted to Bedrock. We’ve had dozens of small and large issues and have been bug hunting for days. The addition of /wp/ to admin paths and transformation of wp-content/ to app/ create many unexpected issues.
Specific issues include filters, rewrites, embeds, and redirections that stop working, 404s on incoming links, and now Cloudflare WAF rules that block editing.
I do like the Bedrock structure and it’s great for development. But is there any strong reason to keep it on production?
There’s nothing for us to go off of from this comment. Which exact plugins are causing problems? If it’s not from 3rd party plugins, what are you doing in your code that’s causing these issues? Have you done any sort of troubleshooting so far?
It’s pretty simple stuff, usually, like using site_url instead of home_url.
I can’t tell if this is a serious question — but you can find some information about Bedrock’s features from our Bedrock page.
I’m quite biased, but in my opinion a vanilla WordPress installation shouldn’t be used for any sort of site or project that you’re taking seriously. If you’re a professional and getting paid to build websites, you should be using something like Bedrock for WordPress projects.
The current issue is that Cloudflare’s Web Application Firewall will block all attempts to edit a Gutenberg page. This is a significant bug for us, was seriously difficult to troubleshoot as there’s no error message, and we still haven’t found a work-around.
I understand the value of the Bedrock file structure in development — it’s extremely logical and frankly sane.
When we used managed hosting that did not support Bedrock I simply added a deploy script that de-Bedrocked our structure before rsync. Basically we build Bedrock in the deploy container, and then rysnc the plugin folder to production’s wp-content/plugins/ folder, and rsync root files as needed. It was less painful than expected.
But if we essentially never need to ssh into production to tool around in the file structure, I don’t see that Bedrock offers benefits on production. It doesn’t affect load times and the security benefits of an isolated web root seem modest. The drawback is increased instability from plugins and service providers including major providers like Cloudflare.
I don’t mean to disparage Bedrock — I’ll never switch back, it’s become a core dev tool. My question pertains to the production server alone.
And you think that this is happening because WordPress is installed in a subdirectory at /wp/? There’s nothing in Bedrock that would be causing this to happen
There’s lots of good managed WordPress hosts out there that support using Composer in production without needing some wild workarounds
Don’t use it on production then?
It seems odd to link your Cloudflare issues with Bedrock, and then also determine that Bedrock isn’t stable since you’re unable to figure your problem out.
Yes, Cloudflare offers OWASP ModSecurity Firewall Rules for WordPress. Those rules include the following:
WP0003 Wordpress - Bypass WAF for /wp-admin
WP0004 Wordpress - Bypass WAF for /wp-admin/post.php
Neither of these appear to be working because Bedrock admin URLs have /wp/ in the path. The details of these two rules aren’t available and I’m working on manually recreating them for Bedrock. Without these rules OWASP interprets Gutenberg editing as a security threat and blocks the requests. Because this error presents as a caching error not a firewall issue we burned a lot of dev hours sourcing this conflict.
I agree. We’re on SpinupWP now which is great and has Bedrock support baked-in. We still don’t build on the server, though, because we’ll be running extensive testing during deploy and we don’t want to bog our high-traffic production server. We use Github Actions for the build and deploy. I have no complaints with this workflow.
Building in Bedrock and deploying as standard WP structure wasn’t particularly wild. It wasn’t any harder to do than rsyncing with the Bedrock structure.
Well, that’s why I am asking the community about this. I wanted to gauge how many Bedrock users run standard structure on production.
I don’t think Bedrock is unstable itself. But it’s definitely added challenges in our project because our existing coding practices and third-party integrations either weren’t compatible or added complexity. I don’t think it’s unfair to mention that Bedrock support is far from universal even among big providers.
The point that I’m trying to make is that Bedrock itself isn’t doing anything special. Bedrock happens to install WordPress in a subdirectory. This is something that is supported by WordPress core, and is used by quite a lot of folks that aren’t specifically using Bedrock — or even using Composer.
I’m guessing that most folks using Bedrock aren’t just using it for development. Trying to use Bedrock in only a single environment sounds complicated and prone to lots of issues. The idea of using it just for development but not production is awkward. We believe it’s important to keep environments in parity as much as possible.
I think your Cloudflare specific questions warrants its own topic either on here and/or the Cloudflare community. It should be pretty simple to setup some allow rules to prevent your issues.
Every site I do (and there are many, now) are developed on bedrock and deployed (to production) with bedrock. Using trellis makes this easier. I have about 30 sites now using trellis/bedrock on VPS hosting, and using it has improved my life as a developer immensely. Thanks to the roots team I’ve not had a reason to deploy vanilla Wordpress for years.
Bit late to reply here, but I can’t imagine building and deploying WordPress without Bedrock now. The first time I converted a site over, I had lots of issues like you, but that’s because devs would take shortcuts and hard code images or content to the uploads directory.