When automatically deploying your WordPress site from version control, you'll want to make sure that your repository is configured correctly. Since your configuration will deploy based on how your source is set up, incorrectly setting up your repository can lead to data loss.
In this article, we'll go over some key points to consider when automatically deploying from version control.
Initial Setup: Mirroring Production
If your code doesn't already live inside version control or is running behind your production environment, the first thing you'll need to do is get it all synced up. When a deployment happens, anything on the destination site will be changed to match what's in your repository (unless otherwise excluded. We'll cover more on this later).
For situations when version control is either being set up for the first time or needs to be fully updated from a production site, your best course of action is fairly straightforward. Just pull down a copy of your site's code, then push it up to your repository. When doing this, just be sure that you don't have any existing deployments running quite yet, as you might need to set up a few exclusions first.
Excluding WordPress Core Files
Since your WordPress updates are handled for you inside of Pagely, you'll want to avoid committing WordPress core files. To do this, you the following rules can be added to your
# Ignore WordPress core files*/ wp-content/advanced-cache.php wp-content/wp-cache-config.php sitemap.xml *.log /wp-*.php /index.php license.txt readme.html wp-admin/ wp-includes/ xmlrpc.php wp-content/cache/ wp-content/backups/ wp-content/mu-plugins/pagely* wp-config-hosting.php wp-config.php sitemap.xml.gz
Depending on how you've configured your site, there may be others you'll want to exclude as well. Be sure to check over your files and set up exclusions for anything unnecessary, such as cache and backup files.
In most scenarios where an entire site is being kept inside version control, the repository's root directory should only contain a wp-content directory.
Note: If you're using our integration system and Docker image to deploy your site from version control, many of these will be excluded from the upload for you, even if they exist inside your repository. For more information, see the section later in this article that discusses deployment exclusions.
Excluding Development Files
In addition to excluding WordPress core files, you'll likely also want to exclude files that pertain to your local development environment. Here's an example .gitignore to get your started:
# Development environments .lando.yml .idea/ # Databases *.sql *.sql.gz *.sqlite # Logs *.log # Build files node_modules/ # Compressed files *.zip *.tar *.gz *.rar # OS files .DS_Store
Depending on how your site is built and your development workflow, you may need to add or remove some of these from this list. For any files that you need to have inside of your repository but don't want to deploy, you can exclude them on deployment.
For any files that you still need to have inside of your repository but don't want to deploy, integrations that use Pagely's deployment Docker image allow for exclusions to be set.
When using Pagely's deployment integration system, the following files are excluded by default:
/sitemap.xml /wp-*.php /index.php /wp-admin/*** /wp-includes/*** /xmlrpc.php /db-config.php /wp-content/index.php /wp-content/advanced-cache.php /wp-content/object-cache.php /wp-content/wp-cache-config.php /wp-content/uploads/*** /wp-content/blogs.dir/*** /wp-content/upgrade/*** /wp-content/backup-db/*** /wp-content/mu-plugins/index.php /wp-content/themes/index.php /wp-content/plugins/index.php /wp-content/languages/index.php /wp-content/mu-plugins/pagely-*/***
Excluding Additional Files
If you have additional files within your Git repository that you need to ignore when deploying to Pagely, you can create a
.pagely/pagelyignore file. This file can can ignore individual files or directories, relative to the respository's root, like this: