WordPress development workflow & best practices. Zgraya style

WordPress is at the very “Core” of our web development.

We love our WordPress.

So we wanted to share some tricks and tips on how we approach the development and make those gigs efficient, fast, and fun.

To read this, you might need some understanding of web dev processes and terms. If you’re not really into such stuff but still curious about our process, we’ve got just the guide for you.

#1. Make it “Local, Staging, Live”

In the beginning, there is always design; and Zgraya design is created in Figma. Then it gets transferred to our devs. And then they start coding.

There are a number of ways to work with code.

The first one is to start developing on a live server right off the bat. You change something, and visitors see the changes on the website right away. This approach is often referred to as “cowboy coding,” and it covers any form of meddling with the code that directly affects a live website.

When you develop on a live site, you risk breaking things that are, well, live.

Imagine this: you’re working hard on a payment system update on your live e-commerce website. With 1,000,000 visitors per month. 

Then something goes wrong — and boom! — your visitors can no longer buy a product. Business starts losing money, customers are upset, and so are the managers. Not so cool, huh? 😉

As you probably have already guessed, we think that “cowboy coding” is a bad idea.

The more reasonable alternative is to develop WordPress websites locally, on your own computer. This creates a much safer environment for editing your files and writing the code:

• No White Screen of Death™ on a live website;
• Local site loads and displays changes faster;
• You can tinker with the code;
• Allows using a version control system (you do use a version control system, right?);
• Allows using task runners (gulp), webpack, CSS preprocessors, image optimization, etc.

That’s why local WordPress development is our champion.

In the past, devs would use instruments like Vagrant, VVV or XAMPP for localized development. But all of them require additional setups to work with WordPress.

This is where Local by Flywheel comes into play. Which is like Git but for WordPress.

Local development allows you to deploy a WordPress environment on your computer in just a few clicks. That simple, yes.

Flywheel created an amazing hosting for WordPress websites. We host our very own zgraya.digital there, and this is the hosting solution we recommend to all of our clients.  

The reason for it is that Flywheel is not just a hosting. It is rather a full-fledged environment configured specifically to work with WordPress.

One of the cool features is the Staging Site.

Staging site is basically an interim milestone between the local websites and the live ones. This is exactly where we check that all of the new edits are functioning perfectly well with the real server. This is also where we demonstrate the new updates to our clients before pushing them onto a live version.

Once we have tested all the new updates, it is the time to transfer them onto the real thing. With Flywheel, we can do it in just one click.

#2. Database Moves Down, Code Moves Up

When the website is live and/or there are a couple of devs working on a project, we stick with another flow:

Code goes up, Database and Media Files go down.

Here’s what it means.

First of all, the “code” — all the files of a WordPress theme —  is transferred from the local environment into working environment – ie. “Up↑”.

Then the database and the media files are transferred from the Live environment into Staging and, finally, into the local environment – ie. “Down↓”

Almost everything that is managed by WordPress admin page (notes, pages, plugins, and themes) is being saved in the database.

#3. Use a Version control tool

Another thing that is a core part of a proper development process is a framework for version control. We always use Git and Github to manage our code. Especially when the project is run by a team of developers that work on the code simultaneously.

Just to make sure that no one breaks other people’s work.

We usually use the repository only to store a WordPress theme, as it contains all the code we create. The rest of the assets we use (WP core, database, media files, and plugins) are controlled via Local and Flywheel.

Should we need to write our own custom plugins, we usually create additional repositories to store them.

Some developers tend to use repositories to store the whole website. We think it is not particularly convenient as one has to deal with a huge number of files. Whereas if you have the theme, you can concentrate solely on what you write.

#4. Here’s to the Starter Theme!

Starter Theme is the core theme that we use as a platform for most of our websites.

With it, we can skip jumping through the same loops every time we start working on a new website. Like creating the menu, basic pages and styles for them, setting up js and scss file assembler, and other basics.

We get all of the above but just cloning the repository with the Starter Theme. Fast & simple.

We’re often asked, “where could one find a good starter theme?” Well, here is a couple:

• Underscores (made by Automattic)
• Roots
• Bones

They work and they are pretty good. But, please, keep in mind that the best Starter Theme for you is…

A CUSTOMIZED STARTER THEME YOU CREATE YOURSELVES!

Nobody knows your code-writing style better than you. And this is why we compiled the best practices we collected over the years and created our own little gem of a Starter Theme that we are in love with.

#5. Modern-Day Tech-Stack

One of WordPress’s strongest suites is simultaneously its main weaknesses — WordPress is built on PHP.

Don’t get us wrong, we love PHP. It is easy to understand, easy to use, and easy to… well, do whatever you want with it. Nonetheless, PHP was never created as a programming language for templates.

Some CMS’s decided to create a workaround to solve the PHP problem. The immediate decision was to use a proper template language.

Template engines compile to native PHP so there is nothing to lose and so much to gain by using a template engine. If you look at any modern template engine like Twig, you will see they compile the templates to source PHP. The output is the same as if you had made the page in PHP by hand.

But the template engines know how to compile the PHP page better than a person because they are maintained by thousands of people. 

Twig is essentially a modern template engine for PHP.

Twig lets you create better templates by using syntax that is very similar to HTML. It’s easier for a non-programmer to pick up than PHP itself; it simplifies a lot of things and is very similar to mustache.

As well as allows to separate logic from templates and helps create code that is better, more efficient, and simpler to maintain. Besides the absolutely beautiful Twig, we apply some of the best front-end dev practices to WordPress theming:

1. ES6+. The WordPress documentation calls it ESNext and even encourages using it.
2. Scss. CSS preprocessing used by WooCommerce and the best way to write CSS.
3. Webpack. Even WordPress core uses Webpack and Babel now.

ES6 and Scss are modern-day JavaScript and CSS, respectively. While Webpack is a tool that lets you use all these features and not worry about backward compatibility. Webpack can be called a front-end app compiler that generates files to use in a browser.

For our more complex solutions, we use a combination of WordPress REST API + React or Vue.js. It leaves us with a convenient admin panel and the whole power potential of front-end frameworks.

#6. Animations and all the “WOW” things 

To make sure our designers can let their imagination go all sorts of wild, we use the capabilities of CSS animations, modern browsers, and GreenSock libraries’ potential to the fullest.

And here’s a decent example of what we can do with it.

#7. Automating. Over and over. Again and again.

We already mentioned Git before. As we use GitHub only to store our WordPress theme, we will automate its assembly and deploy.

To get things rolling, we have two branches: master is responsible for production, while dev takes care of Staging. Remember, we work with Local and Flywheel?

We then use GitHub action to set up automatic code assembly and compilation and to send it over to the server via ssh. It’s secure, and it’s fast.

Should the assembly breed any errors, we get immediately notified of it via our Slack channel.

Working with Git and Auto Deploy allows us to quickly deliver all the updates and changes onto the server and (in case there are unpredictable glitches) to quickly roll back to the last stable version of the code. So no one gets hurt.

In web development, the process is king. Because a well-configured dev process saves you plenty of time.

Saves time = saves money.

A great result here is not only about pristine code; it’s also a derivative of a properly set up production process. 

And there’s is no “right way” to run a development operation. The goal of this article was to shed some light on what works for Zgraya 🙂

Developers have plenty of opinions, feelings, and thoughts on how to approach a development process “correctly.” If you happen to be one of them — look around and choose what works best for you.