On Trac, the system where WordPress core develops the main system, a programmer who creates the WordPress system is called a “developer” or “dev” for short. These are some of the most experienced programmers in the world, and some of the most highly skilled.
Recently, a trend has emerged, originating from overseas design shops, of inflating titles in the WordPress ecosystem so that a designer who fiddles with theme settings has now become a “developer”.
A $50/hour job [a software engineer who knows how to create themes and plugins] is being confused with an $8/hour job [a person with no programming skills who knows how to draw]. There is nothing wrong with this, just be aware when you’re job hunting that when people say the phrase “WordPress developer”, 75% of those speakers mean a programmer and 25% or those people mean a designer.
Welcome to the confusing world of WordPress!
Development operations, or DevOps, is a field of software development that most decidedly isn’t a $7/hour job. DevOps lies at the heart of your business and is the hot trend in 2018!
The basic concept of DevOps is that the human beings who create the company, and the human beings who run the company, should be the same. In the past, it might have made sense to separate the concerns. There was a “wall” between the software people who create a product and the business people who market and run it.
That wall is coming down, and the movement behind it is called “DevOps”.
DevOps in WordPress
WordPress is the largest software ecosystem in the world, and will probably remain so for the foreseeable future. Almost half the Internet runs on WordPress. The ubiquitousness due to that fact that it’s free and open source. There are no barriers to getting into business using the WordPress platform.
WordPress encompasses every form of business and personal blog that human beings can create. There is no one size fits all when it comes to WordPress. Some of the websites on the platform use a shared hosting plan while others utilize a virtual private server (VPS).
What’s the difference? Sites on a shared plan share a single server while those with a VPS use a “virtual” one dedicated solely to their files. Your average blog or e-commerce site will be fine jostling with other websites on the server but larger companies might prefer the freedom associated with having a VPS.
DevOps is an Agile, iterative approach.
You’ll need to architect your workflow in a way that it is iterative. That is, you do step 1, 2, 3, and then repeat [you could have an arbitrary number of steps though]. The point is, that it’s a process. You do the same thing over and over again, getting better and better each time. There are many formal approaches to this: Kanban, Test Driven Development, Scrum, etc. The process builds on previous efforts and goes on forever.
Version Control Everything
Git is your friend. Backups are your friend. Sandboxes are your friend. You need to understand revisioning and version control and make that part of your DevOps WordPress process. There isn’t a specific method that works for everyone, you’ll need to experiment and find what approach works for you.
If your primary business is building content, you are probably already familiar with the WordPress editing and revision process. Just backing up your database and using the built-in revision system will be fine for you. If your business revolves around something your website DOES [like sell stuff], then you’ll need a more sophisticated version control setup to handle custom code.
Git is the standard method used by most developers.
Version Control Your Theme
If you are an agency who cranks out themes for other clients, this advice doesn’t apply to you. If you’re anyone else, you shouldn’t be putting your theme settings in the database. Design elements should be HARD CODED into your theme using HTML and CSS. Why?
WordPress is a sophisticated system designed to be used by all levels of expertise, from children to Fortune 500 companies. Just because something was set up to be used by inexperienced people, or hobbyists, doesn’t mean your business should use that approach!
When you put design elements in the database with tools like the “customizer” or a page builder, you limit your ability to roll them back, or fix things. You can’t just roll back the database, it might contain other changes, like to the content of the site. Another major problem is that it’s difficult to sandbox your theme if it’s in the database.
Instead of fiddling with settings, create a child theme and hard code your changes into the theme. Then version controls the child with git. At this point, you have a repo with all your design elements in it that you can allow anyone to play with without messing up your actual site!
You can spawn duplicate sites and local development sites and allow your team to work anywhere and under any conditions. It’s super easy to give access to a git repo, and super hard to sandbox an entire site.
By using an iterative approach, backing up everything you do, and having the same human beings who design the site run it, well guess what –