The plugin repository still uses Subversion in 2020, and a lot of developers have been frustrated about this for many years already. Most developers use git as their daily source control versioning system, and going back to running svn commands feels like a step back in time to a previous decade. This is kind of true, since Subversion was popular in the 2000’s but has been in a steady decline since and git has been the industry standard at least since early 2010’s. Git is far superior to svn in features and speed, so no wonder developers dislike having to use something inferior after learning about git.

Due to legacy reasons, has not yet migrated to git, and it might take several years more to do so. At the moment developers are stuck inventing creative ways not to have to use svn and instead keep their plugin code in git and use different tools to automatically sync from git (for example on Github) to svn (on


Seravo announced in late 2017 a service to enable WordPress plugin developers to host their code in git on and automatically sync that to without developers having to run any svn commands themselves. The service was built and run in collaboration with Arūnas Liuiza, who presented about it in WordCamp Jyväskylä in February 2019.

At its peak over 250 plugins were synced by from Github to the WordPress plugin repository, but we have not done any further development on it. As of today no more bugfixes will be done and will be completely shut down and stop working on October 1st 2020.

Use Github Actions to sync to introduced in late 2019 a new feature called Github Actions, which is their take on a CI/CD system. This can be used to achieve the same thing did, so we recommend migrating to it using the Github Actions presented below.

For Github Actions to work, two things are needed: scripts in .github/workflows that are run automatically by Github on every git push, and credentials to access

Add Github actions for plugin releases and readme updates

There is no need to constantly sync to It is relevant only on two occasions: when there is a new release that needs to be available to users, or when the plugin metadata such as the readme.txt updates.

New releases are done in this scheme simply by tagging a new version in git. Add this to .github/workflows/wp-release-on-tag.yml that will run on every tag to publish the tagged code on (uses action by 10up):

name: Deploy to
    - "*"
    name: New tag
    runs-on: ubuntu-latest
    - uses: actions/checkout@master
    - name: WordPress Plugin Deploy
      uses: 10up/action-wordpress-plugin-deploy@master
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: seravo

Remember to update SVN_USERNAME to match yours!

Metadata updates don’t depend on tags, but only if the relevant metadata files have been updated or not. For metadata to be updated add this as .github/workflows/wp-sync-assets.yml (uses action by 10up):

name: Plugin asset/readme update
    - master
    name: Push to master
    runs-on: ubuntu-latest
    - uses: actions/checkout@master
    - name: plugin asset/readme update
      uses: seravo/action-wordpress-plugin-asset-update@master
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: seravo

If the Git repository name is not the same as the plugin name on, the plugin name must be defined in an environmental variable SLUG by adding a new row to both of the .yml files:

    SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
    SVN_USERNAME: seravo
    SLUG: plugin-name-on-wordpress-org

Those who used the Seravo Deployer had their assets on a separate branch called assets. For this Github Action to work, the contents of that branch needs to be merged on the main branch. It can be achieved with:

git checkout assets
mkdir .wordpress-org
git mv * .wordpress-org/
git commit -am "Move assets to separate directory in before merge in master branch"
git push
git checkout master
git pull origin assets --allow-unrelated-histories
git push

Store SVN_PASSWORD in Github Secrets

You can use your existing personal credentials, or create a separate machine account on for the purpose. Define the username in the action yml file. Since the password is sensitive, it naturally cannot be visible in the code repository, and therefore it needs to be added to Github Secrets as the variable SVN_PASSWORD, which can then be seen by the Github Action when it runs but otherwise it stays secret. Define this in your repository Settings under Secrets.

Github Secrets
Define SVN_PASSWORD in Github Secrets

If you have everything done correctly, you should see Github Actions in action!

Github Actions running
Github Actions running

Examples in action

To see examples in action, check out for example:

Leave a comment

Read more

In category: Development

Upcoming PHP Updates at Seravo

Since 2022 PHP 8.0 has been the default PHP version at Seravo, and is automatically enabled on all new sites. PHP 8.1 is also available, and PHP 8.2 will be soon available for developers!

January 25, 2023

PHP 8.0 Enabled by Default

PHP 8.0 is the default version at Seravo’s premium WordPress hosting and upkeep. PHP 8.1 also available!

January 8, 2022

When the Internet Breaks – Make Sure Your Website Works

On Monday, October 4th 2021, something quite exceptional happened that did not go unnoticed by Seravo’s customers. Facebook and other […]

October 9, 2021

Webinar: Search Function and How to Customize It

Seravo’s first webinar of 2021 on January 14th: How to use and customize the WordPress search function?

December 30, 2020

What’s new in PHP 8?

On November 26th 2020, there will be a new version of PHP released. This new release has a number of new features, as well as implementing some non-backward compatible changes. Seravo has already started testing and deploying the release candidates of PHP 8.0 to our servers.

November 19, 2020 Calls For PHP 8.0 Testers: Seravo Answers

On October 6th 2020, the WordPress Core team put out a call for testers. Specifically, there was a requirement for […]

October 28, 2020