Git Sync for WordPress Themes and Plugins

Git sync keeps one custom theme or plugin of your WordPress site in step with a private repository on GitHub, GitLab or Bitbucket. A push to your staging branch updates your staging site. When you are happy, the live branch goes to the live site, with a health check and an automatic rollback.

It is on the Staging tab of a WordPress (OpenLiteSpeed) site, in the card Git sync for your theme or plugin. You need the Developer role or higher. For the staging half you need a staging copy of the site (see Staging and Push to Production).

Connect a repository

1. Press Connect a repository and enter the repository address, for example git@github.com:you/my-theme.git.
2. Press Create key and add the public key to the repository as a read-only key. The steps are the same as in Deploy a Private Repository.
3. Press Test connection. When it says Connected, the branches of the repository appear in the lists below.
4. Say whether the repository is a Theme or a Plugin, and the folder name it will have on the site, for example my-theme (that is wp-content/themes/my-theme). If the theme or plugin sits in a folder of the repository rather than at its top, enter that folder too.
5. Choose the staging branch and the live branch (you can set just one), and what a push to the live branch should do: wait for you, or deploy by itself.
6. Press Connect.

Sync

The card shows two panels. Sync staging sends the staging branch to your staging site. Deploy to live sends the live branch to the live site. Each panel shows the last result, the commit and the time, and the card lists the recent syncs.

What happens on a sync

1. FlyNode fetches the branch with your read-only key. Nothing stays running between syncs.
2. It checks the folder: a theme needs a style.css at its top, a plugin needs a PHP file at its top. Links inside the repository are removed, and a theme or plugin above 100 MB is refused.
3. For the live site, the site goes into maintenance mode for a moment.
4. The new files replace the folder. The old version is kept aside, out of the themes and plugins folders.
5. FlyNode checks that the home page and the login page still work and that WordPress still starts.
6. If the check fails, the old version is put back by itself and the sync shows Rolled back with the reason.

A sync never runs while a push, an update or a scan is running on the same site. A push that arrives at that moment is tried again a few times.

Go back to the previous version

Press Previous version to swap the folder with the version kept from the last sync. Press it again to switch back.

Deploy on every push

Press Webhook for pushes to get an address and a secret for your repository's webhook settings. A push to the staging branch then updates staging. A push to the live branch deploys to the live site only if you chose automatic deploys; otherwise the card shows that a new commit is waiting, and you press Deploy to live when you are ready.

• GitHub: Settings, then Webhooks, then Add webhook. Content type application/json, event: just the push event.
• GitLab: Settings, then Webhooks. Paste the secret as the secret token and tick Push events.
• Bitbucket: Repository settings, then Webhooks, with the trigger Repository push.

Good to know

• A sync replaces the whole folder. Files that your plugin wrote inside its own folder are not kept. Keep data in the uploads folder or the database.
• A theme or plugin that is new on the site is not switched on automatically. Activate it in WordPress once.
• Git sync only moves the theme or plugin files. Database changes and content still go from staging to live with Push to Production.
• Disconnect removes the connection and its key. The theme or plugin on the site stays as it is.