Navigating the WordPress.org plugin review gauntlet is a rite of passage, but the process is fraught with legacy pitfalls. Learn from my experience and automate your release workflow to avoid common, painful mistakes and ship your code with confidence.

So You Got Your First WordPress Plugin Approved? Congrats. Now Let’s Automate the Pain Away.

I remember it clear as day. 2 AM. A junior dev, let’s call him Alex, pushes a “tiny hotfix” for our company’s free plugin. He’d been developing in Git like any sane person in the 21st century, but the WordPress.org repo runs on Subversion (SVN). He manually copied the files over to his SVN checkout, ran svn commit -m "Quick fix for issue #123", and went to bed. What he didn’t copy over was the /vendor directory created by Composer. The next morning, our support channels were on fire. Thousands of sites had crashed with a fatal error: Class 'Some\Important\Library' not found. We spent the entire day in damage control, all because of a manual, error-prone deployment process. This isn’t Alex’s fault; it’s a system problem. And today, we’re going to fix it.

The Root of the Problem: Git Brain, SVN World

Let’s be blunt. The core issue is a technical and procedural gap. We live and breathe Git—feature branches, pull requests, automated checks. It’s fast, distributed, and safe. The official WordPress.org plugin repository, however, is built on Subversion, a centralized version control system from a different era. The official workflow encourages you to manually copy your finished code into a local SVN checkout and commit from there. This manual step is a breeding ground for human error: forgotten files, incorrect version tags, and last-minute changes that bypass all your careful testing.

Three Levels of Sanity: From Manual Checks to Full Automation

You’ve done the hard work of building a plugin. Don’t let the deployment process undermine it. Here are three ways to get your code from your Git repo to the SVN-powered WordPress.org directory, ranging from a quick safety net to a fully automated pipeline.

Solution 1: The ‘Do No Harm’ Local Check

This is the absolute bare minimum you should be doing. Before you even think about touching SVN, you need to run your code through the same checks the WordPress.org review team uses. The official Plugin Check tool is your best friend here. It’s a PHPCS ruleset that flags everything from security vulnerabilities to simple coding standard violations.

It’s not automation, but it’s a critical manual gate. You run it from your command line in your plugin’s directory:

# First, install it via composer
composer require --dev wp-coding-standards/wpcs
composer require --dev dealerdirect/phpcodesniffer-composer-installer

# Run the check against your plugin's directory
./vendor/bin/phpcs . --standard=WordPress --report-summary

This is the “quick fix.” It’s fast and effective for a solo developer, but it still relies on you remembering to run it every single time. It won’t catch a forgotten file, but it will catch a syntax error that could take down a site.

Solution 2: The ‘Serious Developer’ Git-to-SVN Sync Script

Okay, so we agree that manually copying files is a recipe for disaster. The next logical step is to automate that copy-and-commit process with a script. The idea is to keep your Git repository as the single source of truth and have a script handle the tedious task of updating the SVN checkout.

Here’s a simplified bash script that demonstrates the concept. It assumes you have an SVN checkout of your plugin in a subdirectory called .svn-repo.

#!/bin/bash
# A simple script to deploy a WP plugin from Git to SVN.

# Your plugin's slug and main file
PLUGIN_SLUG="my-awesome-plugin"
MAIN_FILE="my-awesome-plugin.php"

# Paths
GIT_DIR=$(pwd)
SVN_DIR="$GIT_DIR/.svn-repo"
SVN_TRUNK="$SVN_DIR/trunk"

# Get the new version from the main plugin file
NEW_VERSION=$(grep -i "Version:" "$GIT_DIR/$MAIN_FILE" | awk -F' ' '{print $2}' | tr -d '\r')

echo "Deploying version $NEW_VERSION of $PLUGIN_SLUG..."

# Update the SVN repo to make sure we're on the latest revision
svn up "$SVN_DIR"

# Clear out the trunk and copy new files from Git
# The --exclude array is CRITICAL to avoid copying dev files!
rsync -rc --delete \
  --exclude=".git" \
  --exclude=".github" \
  --exclude="node_modules" \
  --exclude=".svn-repo" \
  --exclude="*.sh" \
  "$GIT_DIR/" "$SVN_TRUNK/"

# Create a new SVN tag
echo "Creating SVN tag for version $NEW_VERSION..."
svn cp "$SVN_DIR/trunk" "$SVN_DIR/tags/$NEW_VERSION"

# Commit to SVN
echo "Committing changes to SVN repository..."
svn commit "$SVN_DIR" -m "Release version $NEW_VERSION"

echo "All done. Version $NEW_VERSION has been deployed."

This is a solid “permanent fix.” It ensures consistency and dramatically reduces the chance of forgetting a file. You still have to run it manually, but it turns a 15-minute, error-prone task into a 15-second command.

Solution 3: The ‘TechResolve’ Way – Full CI/CD Automation

This is how we handle it for our mission-critical projects. We remove the human from the deployment equation entirely. We use a CI/CD pipeline (like GitHub Actions or GitLab CI) that triggers on a specific event, like pushing a new tag to our Git repository. The pipeline runner on ci-runner-wp-deploy-x86-01 does all the work.

The pipeline will:

• Check out the code from Git.
• Install dependencies (Composer, NPM, etc.).
• Run all our checks: unit tests, linting, and the WordPress Plugin Check.
• If all checks pass, it uses secrets to securely access our WordPress.org credentials.
• It then runs a more robust version of the script from Solution 2 to tag and commit to the SVN repository.

Here’s a simplified example of what the deployment step might look like in a GitHub Actions workflow file:

name: Deploy to WordPress.org
on:
  push:
    tags:
      - 'v*'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    # ... steps for installing PHP, Composer, running tests ...

    - name: Deploy to WordPress.org
      uses: 10up/action-wordpress-plugin-deploy@stable
      env:
        SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SLUG: my-awesome-plugin

Darian’s Pro Tip: Never, ever, ever commit your credentials (like SVN_PASSWORD) directly into your code or CI file. Use the built-in secrets management provided by your CI/CD platform. Leaking credentials is a career-limiting move.

This is the “nuclear option” against deployment errors. It’s more work to set up initially, but it pays for itself tenfold by making your releases reliable, repeatable, and stress-free.

Which Path Is Right for You?

Choosing a solution depends on your project’s complexity and your tolerance for risk. Here’s how I see it:

Getting your plugin approved is a huge milestone. Now it’s time to think like an engineer and build a rock-solid process to support it for the long haul. Start with Solution 1 today, work your way towards Solution 3, and save your future self from a 2 AM fire drill.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions