Are you struggling with WordPress development workflows? Tired of SFTP uploads and manual plugin updates?
This comprehensive guide will show you how to modernize your WordPress development process using Git, Composer, and proper environment management.
By the end of this article, you’ll understand how to:
- Set up a professional WordPress development environment
- Manage WordPress core, plugins, and themes with Composer
- Handle sensitive configuration data securely
- Deploy WordPress sites with confidence across different environments
- Collaborate effectively with your development team
Note: This workflow will not make sense for all types of WordPress sites. If you don’t know what Git and version control are or don’t build sites by writing themes, plugins, etc. – you will likely not benefit from this workflow.
Let’s get started!
The Importance of Version Control for WordPress Development
Version control is essential to any modern web development workflow, including WordPress projects. Version control systems like Git provide a robust and reliable way to track changes, collaborate with team members, and maintain a comprehensive history of a project’s evolution.
If you are working on a complex WordPress project, then using version control offers several key benefits:
- Collaborative development: With version control, multiple developers can work on the same codebase simultaneously, seamlessly merging their changes and resolving any conflicts. This is useful for larger WordPress projects or teams with multiple contributors.
- Reliable code history: Version control systems act as a safety net, allowing you to easily revert to your project’s previous working states if necessary. This is particularly important when making significant changes or experimenting with new features, as you can always roll back to a known good version.
- Deployment and environment management: By maintaining your WordPress codebase in a version control system, you can streamline your deployment process and ensure consistent environments across different stages (e.g., development, staging, production). This helps eliminate the “it works on my machine” problem and promotes reliable, predictable deployments.
- Code auditing and reviews: Version control systems enable code reviews, allowing team members to scrutinize changes, provide feedback, and maintain code quality standards.
- Branching and feature development: Git’s branching capabilities allow developers to work on new features or bug fixes in isolation without disrupting the main codebase. This facilitates a more organized and structured development process.
Given these compelling advantages, it’s clear that version control can benefit advanced WordPress users. However, as we mentioned earlier, if you don’t build your own sites, this might not be the best approach for you.
The Challenges With Traditional WordPress Deployment Workflows
While WordPress is a powerful and flexible content management system, the traditional deployment workflows used by many WordPress developers can often introduce significant challenges and inefficiencies. If you have worked with WordPress in the past, then you will likely have encountered several common issues with these conventional approaches:
- Manual file management: In a typical WordPress deployment, developers often rely on manual file transfers (e.g., FTP, SFTP) to push updates to the production server. This process is error-prone, time-consuming, and lacks a comprehensive audit trail of the changes made.
- Inconsistent environments: Without a robust system for managing dependencies and configurations, it’s common for WordPress sites to suffer from “it works on my machine” problems, where a feature or bug fix behaves differently in the development, staging, and production environments.
- Difficulty tracking changes: Relying on manual file transfers can make it challenging to keep track of the specific changes made to a WordPress site over time. This makes it harder to debug issues, revert problematic updates, or collaborate effectively with other team members.
- Lack of automated deployment: Traditional WordPress deployment workflows often lack the ability to automate the deployment process. This results in a more labor-intensive and error-prone process, especially for teams that manage multiple WordPress sites.
These challenges can lead to increased development time, higher maintenance costs, and a higher risk of production issues.
At RunCloud, we believe that addressing these problems by adopting modern development practices, such as those enabled by the Bedrock boilerplate, can significantly improve the efficiency, reliability, and scalability of WordPress projects – particularly at the enterprise level
Steps for Setting Up a WordPress Project with Git
This guide walks you through setting up a WordPress project using Git for version control, ensuring a structured and organized development workflow. We’ll cover creating a new repository, excluding unnecessary files, and organizing your project directory.
Prerequisites
If you haven’t already, download and install Git and Composer on your local computer. Choose the appropriate version for your operating system.
Note: You will also need to create an account on a supported Git provider. In this tutorial, we will deploy the applications to RunCloud using GitHub.
Install Bedrock WordPress
In this tutorial, we will use Bedrock to maintain and develop WordPress locally. Execute the following commands on your local computer to create a new project and change the directory to the new project:
composer create-project roots/bedrock my-wordpress-site
cd my-wordpress-site
Setting Up Your .env File
After creating the project, you will need to configure the local development environment. Environment variables are crucial for maintaining secure and flexible WordPress configurations across different environments.
Bedrock uses the PHP dotenv library to load environment variables from a .env file, keeping sensitive information out of version control while allowing different configurations for development, staging, and production environments.
Execute the command below to create a sample .env file in your project.
# Copy the example file to create your .env
cp .env.example .env
After creating the file, you can edit it to configure your local database credentials. Copy and paste the following code snippet into your .env file and edit the necessary fields to include your database name and credentials:
# Database connection settings
DB_NAME='your_database_name'
DB_USER='your_database_user'
DB_PASSWORD='your_secure_password'
DB_HOST='localhost' # Use 'localhost' for local development
# Use actual host for production/staging
# Optional: Use DATABASE_URL instead of individual settings
# DATABASE_URL='mysql://user:password@localhost:3306/database_name'
After editing your database credentials, you can edit your WordPress environment settings. Copy and paste the following code snippet into your environment file and edit it accordingly:
# Environment type
WP_ENV='development' # Options: development, staging, production
# Site URLs
WP_HOME='https://example.com' # Your site's home URL
WP_SITEURL='https://example.com/wp' # WordPress core location
Finally, you must add authentication keys and salts to your .env file. You can use any random string of text or generate these values using the WordPress Salt Generator and add them to your .env file in the following format:
# Authentication Keys and Salts
AUTH_KEY='your_generated_key'
SECURE_AUTH_KEY='your_generated_key'
LOGGED_IN_KEY='your_generated_key'
NONCE_KEY='your_generated_key'
AUTH_SALT='your_generated_salt'
SECURE_AUTH_SALT='your_generated_salt'
LOGGED_IN_SALT='your_generated_salt'
NONCE_SALT='your_generated_salt'
While working with a .env file, there are a few things that you should keep in mind:
- Never commit your .env file to version control
- Use strong, unique passwords for database credentials
- Generate new salts for each environment
After editing the .env file, you can save it and visit your WordPress URL to view your site locally.
Note: This step assumes that you already have a webserver daemon, such as Caddy, Nginx, Apache, etc., running on your local machine to serve your WordPress website at the specified address.
Initialize Git Repository
Once your website is up and running, you can initialize a new Git repository using the following command:
git init
git add .
git commit -m "Initial Bedrock project setup"
The above command will create a new git project in your WordPress directory. You can now start tracking it via version control. However, most people use a Git server, such as GitHub or GitLab, to manage and collaborate with other developers.
In this example, we will use GitHub to manage and track the changes in this repository, but RunCloud supports multiple Git providers. To do this, create a new empty repository in your GitHub account and do not initialize it – i.e., ensure that “Add a Readme” is unchecked.
This will create a repository without any content. On the repository dashboard, scroll down to the bottom and look for the following commands:
git branch -M main
git remote add origin [email protected]:tatticoder/wordpress-composer.git
git push -u origin main
Note: Do not copy the above commands; they are only provided as an example. You must copy the commands specific to your git repository.
Once you find the necessary git commands in your git dashboard, go back to your terminal window and execute them. After you push the changes, your local code repository will be uploaded to the cloud.
Deploy WordPress via Git on RunCloud
After uploading your Git repository to the cloud, you can deploy it to your RunCloud server. The deployment steps are straightforward, but if you need step-by-step instructions, refer to our documentation on Git deployments.
After creating your git application on RunCloud, you will need to upgrade it to an Atomic Deployment project to take advantage of additional features. To learn more about this, follow the steps outlined in our documentation on Atomic Deployments.
Next, you must create a new database for your web application in the RunCloud dashboard. Take note of the credentials created in this step, as we will need them later. Optionally, if you are using a Docker server, you should read our documentation on networking in a RunCloud containerized server before moving on to the next step.
After that, you will need to configure a new environment variable file using Symlink for this website before you can use it. To do this, navigate to the “Symlink” tab in your atomic deployment dashboard and create a new configuration file. Next, add .env in both the “Link From” and “Link To” fields as shown below.
After this, you can add a secure passphrase to lock your configuration file. You will need this passphrase again if you want to edit your file later.
Finally, you can configure your Bedrock environment variables to meet your requirements. Here, you must add the database credentials you created earlier and configure the host if you are using RunCloud docker. This setup process is nearly identical to the “Setting up .env file” step we covered earlier.
After configuring your .env file, you must configure your web application’s public path to point your web server’s document root to the web directory within the Bedrock project. You can also connect your database to your web application to ensure it is backed up properly via the RunCloud backup service.
To do this, go to your web application dashboard and navigate to the Settings tab. Select the database you created from the drop-down menu on this page and click Update Linked Database.
Next, make sure that your web application’s public path ends with /live/web. Finally, change the web application type to WordPress from the drop-down menu. Once you hit Update Stack, your website will be accessible to everyone on the Internet.
After deploying your application, you can view it by clicking Open Site in your RunCloud dashboard.
Configure Cron Jobs (Optional)
After deploying your application, you can configure your .env file in the production environment to disable the default WordPress cron job. Once you have disabled the cron job, you can use the RunCloud dashboard to configure a new cron job for your WordPress site.
While configuring your cron jobs, use the correct public path for your WordPress installation. If you followed the steps correctly, then the complete WordPress path will look something like this:
/home/runcloud/webapps/application-name/live/web/wp/
You can use the above path to run PHP cron commands on your server. For example, you can run the following command to execute the PHP cron file directly:
php /home/runcloud/webapps/application-name/live/web/wp/wp-cron.php
Developing With Git Workflow
When working on a new feature or bug fix, it’s recommended to create a dedicated Git branch for that work. This allows you to isolate your changes and collaborate more effectively with other team members. You can create a new branch from your Bedrock project directory with a command like git checkout -b feature/my-new-feature.
After you’ve completed your work on a feature branch, you can merge those changes back into the main development branch (usually main or dev) using a Git merge command, such as git merge feature/my-new-feature. This integrates your feature into the codebase and makes it available for deployment.
If you have configured a webhook for your application (as described in Atomic deployment documentation), then your live website will be updated automatically as soon as you push your changes to the cloud.
Handling Modified Files Not Managed By Git
While Bedrock encourages managing most of your project’s files and configurations in Git, some files, such as wp-config.php, may contain sensitive or environment-specific information you don’t want to commit to your repository.
In these cases, you’ll need to deploy these files separately, perhaps using environment variables or including them in your deployment process.
Similarly, user-generated content, such as media uploads, is typically not managed in your Git repository, as it can quickly bloat the repository size and is more efficiently stored and served directly from the web server.
During deployment, you’ll need to ensure that these non-Git-managed files are properly transferred to the deployment environment, either as part of your deployment process or through a separate content synchronization step.
Managing Themes And Plugins as Composer Dependencies
Bedrock uses Composer, a dependency management tool for PHP, to install and manage the WordPress core updates, plugins, and themes. This allows you to easily update WordPress core by simply updating the Composer dependency rather than manually downloading and replacing files.
Installing third-party plugins and themes
Bedrock encourages you to manage your project’s themes and plugins as Composer dependencies as well. This is done by specifying the required plugins and themes in the composer.json file.
For example, to install the Akismet plugin, you would run composer require wpackagist-plugin/akismet. Composer will then fetch the plugin from the WordPress.org plugin repository and install it in the appropriate directory for your Bedrock project.
Handling private/premium plugins and themes
For private or premium plugins and themes that are not available on the WordPress.org repository, Bedrock provides a way to include them as Composer dependencies as well. This involves configuring custom package repositories in the composer.json file, such as a private Git repository or a custom Composer repository provided by the plugin/theme vendor. This ensures that your project’s dependencies are all managed consistently and are version-controlled.
Keeping WordPress Core And Dependencies Up-To-Date
One of the key benefits of using Composer with Bedrock is the ability to keep your WordPress core and all other dependencies up-to-date. When a new version of WordPress, a plugin, or a theme is released, you can simply run the composer update command to fetch the latest versions.
Bedrock also provides a composer outdated command to help you identify which dependencies have newer versions available, making it easy to stay current on updates and security patches. You can consult the Bedrock documentation for more details and advanced usage scenarios, such as handling database migrations, configuring environments, and integrating with continuous integration/deployment tools.
Conclusion
By separating WordPress core from your custom code, managing dependencies with Composer, and adopting a Git-based development workflow, you can enjoy several benefits:
- Improved version control and collaboration for your team
- Easier management of WordPress core, plugin, and theme updates
- Consistent and reproducible development and deployment environments
- Enhanced security through the use of environment-specific configurations
- Streamlined deployment processes, potentially with automated CI/CD pipelines
The WordPress ecosystem has evolved significantly over the years, and developers must keep pace with modern development practices. By embracing tools such as Git, Composer, and Bedrock, you can elevate your WordPress projects to a new level of maintainability, scalability, and efficiency.
If you’re a developer & still manage your WordPress sites without Git, we highly encourage you to explore the benefits of the Bedrock approach and adopt these modern WordPress management practices. They will not only improve your development workflow but also make your WordPress sites easier to maintain in the long run.
Naturally, we recommend using RunCloud, a powerful server management platform that makes setting up the ideal WordPress development workflow as well as managing production-grade infrastructure even easier.
RunCloud seamlessly integrates with your Git-based WordPress projects, allowing you to automate deployments, manage environment-specific configurations, and ensure consistent deployment environments.
By combining the benefits of Bedrock’s Git and Composer-based approach with RunCloud’s server management capabilities, you can create a streamlined and efficient WordPress development and deployment workflow.
Sign up for RunCloud today and take your WordPress projects to new heights of productivity and reliability.