Bedrock for different situations


I have been playing around with Bedrock and thinking about how I would use it in different situations.

There are definitely situations that I would not use capistrano, and because of this I was thinking I wouldn’t use dotenv either. I am thinking that together they make sense, but apart not so much.

That being said I am really liking the folder structure of Bedrock and using composer. The below is what I have been thinking of doing and worked out so far. I am wondering if there are any concerns I should be aware of, or ideas to make it better.

  1. Download Bedrock from git.

  2. Before running a ‘composer install’ I do the following:

  • delete Capistrano files per documentation (remove deploy folder etc.)
  • delete scripts folder
  • delete dotenv files per documentation (remove environments folder etc.)
  • open composer.json and delete references to the installer and salts, and phpdotenv
  • open composer.lock and delete phpdotenv
  • keep application.php, but replace the dotenv references
  1. Run ‘composer install’

I’ve tested and it works.

From here I am thinking of keeping this as a repo on Bitbucket and deploying it through Deployhq for new projects. I would need to manually change the credentials of course.

Any thoughts on this? Is this completely weird and defeating the purpose of Bedrock?

Regarding point 7, I would delete the lock and run composer update to generate a new one.

Removing Composer would be the only purpose defeating change to Bedrock. There are other ways to manage credentials and deployments. So carry on if it’s working well for you.

Just a note about step #5:

Dotenv and the .env file has nothing much to do with the config/environments folder. I’d still keep that. It’s just nice organization for configuration options across dev, staging, production etc.

The rest looks fine.

Thanks for comments. I am also thinking about adding a local-config file and conditional much like wordpress-skeleton. In git I am gonna try separating out Bedrock and dependencies into its own branch and theme in its own. Then keeping it all in one repo on bitbucket. We’ll see how it goes.