Originally published at: https://roots.io/a-modern-wordpress-example/
Roots now has quite a few projects, and as we’re constantly improving them, it can be difficult to understand how to configure and get them all working together. As much as we try to provide documentation and support, the easiest way to learn is still to see a working example and some code in action.…
This will help me a lot to get my head around Bedrock and Bedrock-Ansible.
Is there any plan to update the Modern WordPress Example project with the latest Bedrock and Bedrock Ansible? It looks like a lot has changed in just the last 8 days (Capistrano removed, documentation, etc.).
I’m struggling to see how the parts fit together with the current documentation for each of the 3 projects: Bedrock, Bedrock Ansible, and Modern WordPress Example. I’m taking each of the projects’ installation documentation step by step and it’s disjointed. The Bedrock documentation references the Ansible project and vice versa, but it doesn’t come together in a complete step by step setup that’s easy to follow.
Yep, we’ll be updating it although not always right away since it can’t be an automatic process.
@merchantguru are you saying you’re still struggling to understand how they fit together even with the new example project? We hoped that it would be the missing piece although we do need to document it a bit still with a README.
This is awesome but I am still trying to work it out. So I could literally clone this and get it up and running on DO?
Yep, I believe the only thing you’d have to change is the host IP.
edit: and if you’re actually going to use that server then the passwords as well.
OK I’ll give it a go! Any chance of a very quick step by step?
Yes, still confused. Here’s what confused to me:
-
Do I set up Bedrock first or Bedrock Ansible? I started with Bedrock, then got to
.env
and was not sure if the credentials would be created by Bedrock Ansible on a local vm similar to how VVV sets up the local dev wp-config. So, I switched to setting up Bedrock Ansible, and eventually the instructions there assumed an existing Bedrock site (Installation #3). Since roots aims to be DRY, I assumed I would not need to edit the Bedrock.env
and then again ingroup_vars/development
. -
The projects are out of sync, e.g. the example project refers to Capistrano and
composer create-project
, but the updated Ansible does not. I’m confused whether I should usecomposer create-project
or not. -
If I were to create a
myproject
folder and git clone both repos, that would create sub directoriesbedrock-ansible
andbedrock
, notansible
andsite
like in the example project. The Bedrock Ansible project’s example showsbedrock-ansible
andexample.com
. It’s not immediately clear what the project structure should be… might be clearer in the example if you made the directoriesbedrock-ansible
, andbedrock
orexample.com
like the Ansible documentaion example, orroots-example-project.com
- just be consistent among the three repos. -
Why is the
Vagrantfile
in the project directory instead of theansible
directory like from the Bedrock Ansible repo? Was it moved, and why? -
After running
vagrant up
, it got most of the way and failed. I think I saw the failure noted somewhere else in the forums so I don’t think it’s unique to me (I can’t remember, but I think it was related to “couldn’t find SSL” or something). I gave up at this point. I didn’t even get to setting up Sage, which I assume is point 4: “Add theme(s)”. Where?
I think most of this could be solved with:
A) Keeping this example project up to date with the other two projects, especially b/c old readme files show up in the example, and then the user has to decide which instructions to follow. It’s hard to try to set up the new bedrock stuff while following an old example.
B) Use consistent folder names, domain examples, etc. between the three, e.g. roots-example-project.com everywhere instead of example.com.
C) Step by step “unified” instructions actually following the two Bedrock repos with cut and paste command line examples for every single step, including stuff that might be obvious, but actually isn’t. E.g., if you endorse a directory name change, then show command line steps like: mv bedrock site
or mv bedrock roots-example-project.com
or
cd myproject
git clone GitHub - roots/bedrock: WordPress boilerplate with Composer, easier configuration, and an improved folder structure roots-example-project.com
cd roots-example-project.com
composer install
I’m still confused as to whether Bedrock-Ansible helps to scaffold Bedrock and/or Sage. Or, does composer install create-project
help in anyway? The way I guess I thought this would kind of work (and this is probably way off base) is to run bedrock-ansible and that would set up the local dev with vagrant/virtualbox, and then set up bedrock, and then set up Sage. Ideally, ansible (or something else) would give the option whether to do a fresh Bedrock and/or Sage install. And prompt in some way whether to set up a staging and production server, too.
Thanks for this. It’s great feedback.
A lot of those issues will be addressed by just having a README
on that project. Going to through your points this weekend and make sure everything is clear.
Was able to get the roots-example-project running. On thing i had to do before running vagrant up was to go to the ansible folder and install the roles package.
ansible-galaxy install -r requirements.yml -p vendor/roles
My flow was as follows
- clone roots-example-project into folder roots-example-project.dev
- cd /ansible and ran
ansible-galaxy install -r requirements.yml -p vendor/roles
. I had an error running vagrant up without the roles package which was documented here : https://github.com/roots/bedrock-ansible#installation - Once the roles package was installed I ran
vagrant up
from the root of roots-example-project.dev folder - once vagrant did it’s thing I was up and running, hosts file, db, env vars & wp credentials all setup. No other config file was needed to be manually setup, keep in mind i kept the domain the same as the roots-project-example.dev
- wp login at roots-example-project.dev/wp/wp-admin/ - admin/admin
@merchantguru is correct on how disjointed the process feels when trying to make sense of things. I am a total noob when it comes to Vagrant but was able to get this running. A single documented flow would focused where I should be looking if I run into errors. Although the documentation is there (kinda everywhere) it took me some time to understand and connect the dots myself between everything.
I’m going to try this using @buretta’s steps. I attempted it by trying to work off the Bedrock and Bedrock Ansible repo’s and referencing this project as a guide. Can you provide guidance whether this Example is meant to be cloned and used if one is going to use both projects anyway, or if this is mostly just an example and utilizing the individual projects is preferred.
@merchantguru I’ve made a few changes based on your feedback:
- Updated bedrock-ansible’s README to have consistent folder naming + linked to the example project
- Started to work on a README for the example project: https://github.com/roots/roots-example-project.com/blob/readme-instructions/README.md
Please let me know about any feedback you have on that.
I’m also going to be referencing the example project in Bedrock’s README as well.
the roots-example-project repo is what the end goal should look like if you choose to use bedrock and deploy with ansible. If you clone the example you get the entire setup without going through all the steps that the readme now provides. If you follow the steps you learn the process top to bottom, if you use the roots-example-project you pretty much bypass them but end up at the same result…just less understanding of how you got there
If you do use the roots-example-project the following worked for me
- clone it into whatever project folder you are working from
- BEFORE you run
vagrant up
ensure that all the required ansible packages are there as per the instructions here: https://github.com/roots/bedrock-ansible#installation - BEFORE you run
vagrant up
make sure you editansible\group_vars\development
and have you dev url in there. Edit betweensite_hosts
andphp_error_reporting
- Run
vagrant up
from your project root where the vagrantfile sits - Start working.
- Have some tea, post a thank you to @swalkinshaw and the rest of the team for being so amazing!
That worked for me
Ran through it twice already with other projects, not just using the example domain.
Step 3 of Instructions is missing the ANSIBLE_PATH change.
ANSIBLE_PATH = 'ansible'
true, I think the roots-example-project has already adjusted the path so I skipped that step. That also illustrates what happens when you use roots-example-project without going through the documentation from start to finish, you end up not knowing what settings are actually needed to be adjusted.
I haven’t gotten to deploying with Ansible yet so my steps reflect getting the site up and running if you clone the roots-example-project.
This is excellent, when you’re self-teaching, examples are invaluable.
One thing I’d like to see added to the readme is the DO droplet you recommend using. I was stuck for a while during setup of my production server when Mariadb kept being unable to set the db’s root password. Finally, I spun up a premade LEMP droplet and everything worked just fine. (now I’m stuck at deployment, but I’ll get there eventually.)
Thanks so much.
Thanks for incorporating the feedback on those projects. Helps a lot!
@evanfuture, I got stuck at the same (TASK: [mariadb | Set root user password] Operation CREATE USER failed for 'root'
) and was just about to troubleshoot it when I saw your comment. I might spin up a LEMP server now to see if that gets me by… although Ansible should normally handle this.
@evanfuture I solved this by deleting the root user with the password problem. The error was that the root user was already created, so it failed at this step. I SSH’ed into my droplet, then:
SELECT user, host, password FROM mysql.user;
DROP USER 'root'@'mydropletname';
Re-ran the ansible playbook and it continued past this step.
Both of our solutions seem outside what should be happening with Ansible. Is there a way to add your task to the roles perhaps?
They acknowledged it’s probably a bug. It happens (at least in our cases) when the playbook is re-run. I posted a GitHub issue here. Running drop user is a workaround in the meantime.