Creating the perfect flow for your WordPress apps - Q&A

What a webinar that was! We tackled down some issues critical for a fluid and automated WordPress workflow, from managing different environments to test automation.

We didn't have time to answer all of your questions during the webinar, that's why we decided to respond to all of them in this article. Enjoy!

Drew: "How do you handle multiple WordPress databases on developers' local machines, and turning them into one proper database on a staging site? We have tried a few different approaches but nothing seems elegant."

Managing DBs across different environments is a hindrance for agencies and freelancers alike. Unfortunately, in the WordPress realm, there isn’t anything like GIT that would help us solve this problem. At OsomStudio, we’re trying to use the production DB as the source of truth. Every developer that starts working on a project on their local machine must pull the DB using the WP Migrate DB plugin and import it locally.

It gets more complicated when you reverse the process as we really can’t push the DB from a local machine to the server. If we do that, we overwrite our client’s setup, which is unacceptable. So at this point, the only thing to do is to replicate and apply the changes developed locally again, but this time in the production environment.

The only thing that makes our work a bit easier is exporting data from groups of fields from the ACF. Thanks to that we can easily import them to production, which saves us a bit of precious time.

It’s worth noting that the guys at Delicious Brains (the fathers of WP Migrate DB) tried to develop a solution that would alleviate all problems related to DB handling. Unfortunately, they abandoned this project after a few years of trying and not getting anywhere.

Sam: "What is the future for web development for WordPress and its competition?"

In my opinion, WordPress has no real competitors right now. When you look at the CMS market, you quickly realize that every other solution is playing the catch-up game and losing as almost 50% of CMS-managed sites are built with WordPress. In the near future, the WordPress user base will likely continue to grow and we’ll see the snowball effect in action.

When it comes to the future of web development, I see two possibilities. The first one is the “headless” approach. I think we can all agree that the WordPress dashboard is very user-friendly. The obvious next step is abandoning it and sending data to the front-end through REST or GraphQL APIs. For that front-end, it’ll be best to use a JS framework, such as Gatsby or NextJS.

The other possibility is focusing on generating static sites. In this case, the site gets considerably smaller, which helps to reduce the hosting costs significantly, and loads much quicker for all users. The quicker loading times will get the site a higher PSI (PageSpeed Insight) score and better search engine visibility.

Karen: "What is high-performance website delivery?"

I think that you can get this “high performance” through asynchronous work. To harness it, our company started using Timber, which allowed us to separate the logical layer from the visual layer. This eliminates all of the waiting and chokepoints in the process of creating a site.

John: "Which CI/CD is the best and how does an agency get started with it?"

I was the one who introduced CI/CD in OsomStudio a couple of years ago, and I think that there’s no better solution than Buddy, especially for newcomers. We don’t have to waste time creating complicated configuration files. Instead, we’re building pipelines from blocks, just like playing with LEGOs.

How do you introduce CI/CD? Step by step, incrementally. Implementing all of the elements of the CI/CD methodology isn’t simple. If you do it one step at a time, it turns out to be not that difficult either.

We start with building the assets and deploying to different environments. Next, we introduce the tests that Buddy has built-in, such as Visual Tests, Lighthouse, or Link Validator. It’s really easy!

Last, but certainly not least, we add other tests such as unit, functional, or E2E.

Sylvain: "How do you generate a static version of your website during the workflow?"

You can approach generating static sites in one of the three ways:

• Using a plugin - it’s WordPress after all! My recommendation is WP2Static + WP-CLI + Buddy which gives you full control over the entire process.
• Using a service, such as Strattic. You don’t have the same level of control over the process, but everything’s done for you automatically. We even hosted a webinar with Nate Finch on this approach.
• Using a Static Site Generator. It’s a great solution, especially if you want to use programming languages other than PHP.

You can read more about static sites here.

Edwind: "How we can track the DB changes between updates?"

In this case, it’s best to keep a separate changelog for this purpose and have it updated by all of the involved developers. It allows you to update your local DB when one of the features developed locally uses tables available only on the production server.

Carlos: "why use Timber instead of Sage? Is Twig the only reason?"

Yes, it’s mostly because of Twig. We also support ACF Timber Blocks, which allows us to create Gurenbergowych blocks with just a couple of lines of comments.

I also think that using Twig templates allows you to separate back-end from front-end in a definitive manner. Developers can’t sneak snippets of PHP code into the templates like they could when using Blade templates.

Foofighterdaz: "Advantages of Bedrock vs Docker?"

We’re talking about two different things here. Docker allows you to create containers with different environments.

Bedrock on the other hand is a WP boilerplate which uses a completely different file structure and allows to store them in version control easier.

You can, of course, create a WP with Bedrock running in Docker. Check out this repo for an example.

Piotr: "How do you handle core/plugins/themes updates? and if by using "composer update", how do you handle wp plugins update flow (deactivate plugins before the update, because composer doesn’t do that by itself)?"

As you said, we’re using “composer update”. First, we use the test server and a functionality of Manage WP to check if the plugin is compatible. Safe Update allows us to create a backup before we update the plugin. With this functionality, we can revert to an earlier version of the plugin. If everything is fine we update the composer.json file and send it to the production server.

Mariusz: "Do you/could you provide a default WP setup library for a perfect gitflow eg. from Github/master to the env?"

Sure! Try SasquatchWP.

Piotr: "what about installing/updating languages packages? Also Composer?"

WP-CLI is great for installing or updating language packs. This is what we’re using.