I was contemplating situations when not to use Bedrock and if others think in terms of this also.
There are times when I do a project then pass it off. For various reasons I may not be involved with it anymore.
Anyways, I was wondering if others think there are definitely times when a more “standard” Wordpress install and folder structure is more appropriate. I was actually worrying about a future developer coming in and finding it confusing to do a migration down the road.
Sure, I wouldn’t expect a client who isn’t a developer to manage a Composer-based WP site. However, that doesn’t mean that Bedrock can’t be used during development. When handing the site over, you can relatively easily convert a Bedrock install to a standard WP install. Just remember whether you want to keep the mu-plugins, and to set any of the extra constants that are in the Bedrock project in the standard wp-config.php that you want to keep.
Thanks. I am probably over-thinking this as I often think about making life easier on the next guy.
In my experience using Bedrock for client work I have definitely gotten backlash on rare occasions. Not even backlash for good reasons just some novice/amatuer developers getting uncomfortable.
There has only been like one time where it became a real issue. I explained the bedrock-ansible, bedrock, composer, capistrano process and how it worked and the benefits to the people taking over the project and they FREAKED. Like lost their minds. Completely livid.
“Where is the FTP??”.
The solution was:
“Just kidding, completely ignore everything I said that makes you uncomfortable. Here is the SSH key and you can SFTP into the server like that”.
And everything was right with the world. All the features of bedrock are definitely optional. If people don’t want to reap the benefits then no skin off your nose. I have had way more people go “Oh this is like rails” or “oh nice this is like laravel” than flipped out.
This thread is interesting to me. I have clients with bedrock based sites we’ve built. Some pay me a fee to keep managing the sites once they go live, others don’t but I still usually keep an eye on things for them. I also usually keep the staged version of each site as a daily synced backup and for testing.
I worry that if I don’t test the plugin (etc) updates properly then things might break.
This is particularly true as we do lots of multilingual work with WPML which tends to make the system a bit more ‘brittle’ and liable to break. Gravity forms caused a problem recently for example.
Despite this, I have one client in particular who I think would prefer just a standard WP install. What is the simplest way to convert to that? I was thinking make a fresh install of WordPress and use WP Migrate DB pro or wp-cli to sync the db and files and then add the constants to wp-config.php. Is there a better way ?
I was actually trying to think ahead for this situation when I originally asked the question. I also think you would need to do some further file path replacements for the media files and such. I’ve been thinking about adding instructions to my theme just in case they do a full migration to a more standard WP install.
Don’t worry… you’d probably make him a favor forcing him to learn these tools… I can’t really think of any reason to not use Bedrock. It really pays off.
It’s not your responsibility to worry about the next guy John. Do what’s right for your client but don’t make it harder on yourself—especially if you aren’t getting paid to think about the next guy. He can convert from bedrock if he has to.
While it’s true, you should be developing how you are comfortable, especially if you are setting up the project requirements, code standards, etc. So if you are able to use Bedrock on a project, by all means you should.
However, the other side of the coin is that you should be writing code for your future self and future developers. Does that include not setting up the client’s site using Bedrock? Probably depends on the project. If you KNOW that your client will not be hiring you and hiring another person to manage the site who has no idea what Bedrock is or how to use it, you should probably consider installing the production site as a standard WP install.
That’s not saying that Bedrock is hard to learn. However, in the WP ecosystem where many “WP developers” are not much more than designers/implementers who FTP to their site, not seeing the default structure creates all kinds of confusion. Problem solving skills aren’t always super high either. So it’s definitely something to think about.
Thanks for the comments. Interesting. Yeah, probably thinking about it a bit too much. I may be inheriting a project that looks like it is a drupal to Wordpress conversion built on Sass and Compass. I’m having a bit of difficulty making sense of it as I have been getting a lot of build errors. Thus, I have been contemplating my own standards.
I’ve also been thinking about putting together my own Underscores and Boostrap template for some projects where it may be more appropriate. For what I do, I do hand off projects a lot.
More like this:
Lucky for us, the good folks @ Roots get to do the ongoing development :).
I think it whether or not to use Bedrock totally depends on your hosting environment and setup.
For example, I’m an in-house developer at a large academic institution and our hosting is between a WebDav and shared WAMP server; and our WordPress setup is Multisite.
As much as I’d love, love, love to use Bedrock, the server conundrum (though did I read Bedrock now supports non-*nix systems?) coupled with major db changes for nearly 50+ sites that are edited regularly is quite a lot to undertake.
Happy to hear how others managed this
Bedrock does not require a *nix system. It can be used anywhere wordpress is used really.
My apologies, you cannot use Capistrano on a non-*nix system according to the screencast details.
You can’t use Capistrano to deploy to non *nix systems. You can use Capistrano on a Windows machine to deploy to a *nix server though if you wanted.
Keep in mind that Capistrano was moved out of Bedrock into it’s own repo now as well so there’s nothing tying them together.