Releasing a WordPress plugin on WordPress.org should be exciting, not stressful. Yet, many developers and agencies still waste time building ZIP files by hand, manually copying files, and wrestling with SVN for every release.
In this AI era which is constantly evolving, there’s a better way: automate your plugin packaging and deployment using GitHub Actions.
In this guide, I will walk you through the whole process, from building the plugin ZIP to hands-free deployment, so you can focus on development and business activities.
Why Automate WordPress Plugin Packaging and Deployment?
Publishing a WordPress plugin shouldn’t be stressful or time-consuming. However, for many developers and teams, the traditional approach is full of repetitive manual steps consisting og building a ZIP file, excluding development files, running build scripts, copying files, pushing to SVN, and testing downloads. Let’s explore why automation is a game-changer for plugin authors of all skill levels.
1. Save Hours (and Headaches) Per Release
Releasing a WordPress plugin manually can be surprisingly time-consuming, especially as your project grows or you manage multiple plugins. Each release usually means:
- Double-checking which files and folders should be included or excluded
- Running build tools, compiling assets, and copying the right files to a separate directory
- Creating ZIP files for users to download and test
- Logging into the WordPress.org SVN repository, committing changes, and properly tagging new versions
- Backtracking to fix mistakes or missed steps like forgetting a build command, leaving out a critical file, or packaging the wrong version
With automation, all of these steps happen seamlessly in the background. As soon as you tag a release, your workflow builds, zips, and deploys the plugin automatically. This doesn’t just save a few minutes, it saves hours for every release, especially if you publish frequent updates or juggle several projects. The time saved means you can focus more on building features, improving quality, or growing your plugin business.
2. Reduce Human Error
Manual release processes leave plenty of room for mistakes, even for experienced developers. It’s easy to:
- Accidentally include sensitive or unnecessary files (like
.env, build scripts, test suites, or configuration files) - Forget to update version numbers, changelogs, or asset versions before release
- Miss a build step, which can result in a broken ZIP file or missing compiled assets
- Place files in the wrong directories, especially when working with SVN or unfamiliar release tools
An automated workflow does things the same way, every time — no skipped steps, no missed files, and no last-minute surprises. By enforcing a consistent process, automation significantly reduces the risk of bugs or “oops” moments. Both your users and the WordPress Plugin Review Team will appreciate the reliability and predictability of each release, and you’ll have greater peace of mind knowing your plugin is always published correctly.
3. Ensure Consistency and Professionalism
Every plugin author wants their releases to look polished and reliable, no matter who’s handling the deployment. Automation guarantees this consistency by:
- Packaging and deploying the same files, in the same structure, for every ZIP and WordPress.org release
- Automatically running all required build steps (like CSS/JS minification, asset compilation, and translation file generation) before packaging
- Cleanly tagging and versioning every release, so users and contributors always know what’s changed
- Ensuring users download a clean, production-ready plugin — no extra clutter, missing assets, or broken features
This level of consistency sends a strong message of professionalism and care to your users, agency partners, and fellow developers. It helps your plugin stand out, attracts more contributors, and reassures customers and collaborators that you’re committed to delivering a top-tier product, release after release.
4. Simplify Team and Open-Source Collaboration
Automating your plugin build and deployment makes teamwork and community contributions much easier. Instead of requiring new contributors to learn complicated build scripts or SVN commands, anyone can trigger a release simply by tagging it in GitHub. This removes the need for specialized “SVN experts” and ensures every release follows a consistent, professional process.
Automation also makes onboarding new team members fast and painless, they can focus on coding and bug fixes without worrying about release routines. As a result, your project becomes more welcoming and scalable, empowering a broader group of developers, designers, and translators to contribute with confidence.
5. Faster Hotfixes and Security Updates
When a bug or security vulnerability is discovered, every minute counts. An automated deployment workflow allows you to respond instantly: just commit your fix, tag a new release in your repository, and the entire build, packaging, and deployment process runs automatically. This rapid, hands-off system eliminates the stressful, manual steps traditionally involved in pushing emergency updates like preparing ZIP files, running build scripts, and wrestling with SVN.
Your users receive critical patches and security updates much faster, minimizing exposure to threats and maintaining trust in your plugin. With automation, you can focus on quality and safety, confident that each fix reaches your audience without delay or error.
6. Modern, Scalable Workflow
A robust automated workflow handles everything from pre-releases and beta versions to stable, production-ready deployments — all within the same streamlined process. It’s simple to add automated code quality checks like PHPStan, PHPUnit, or static analysis tools, catching issues before they reach your users.
With full compatibility for Composer and npm, your workflow supports the latest in PHP and JavaScript development. This not only keeps your release process efficient and reliable, but also ensures your plugin development remains scalable and future-ready as your needs evolve.
Take the Hassle Out of WordPress Plugin Deployment
Imagine publishing new features and fixes with a single click, no more tedious ZIP files or SVN commands. Upgrade your workflow and deliver updates to your users faster and more reliably than ever before.
Prerequisites
- A WordPress plugin hosted on GitHub (with a valid
readme.txtand plugin headers). - WordPress.org SVN credentials (for deployment).
- Admin access to your GitHub repository (to add secrets and workflows).
- A
.distignorefile (optional but recommended) to control which files go into your ZIP/deployment.
Automate Your WordPress Plugin Development Workflow
Automating your WordPress plugin development workflow takes the stress out of releasing updates. With the right setup, building, packaging, and deploying your plugin happens seamlessly in the background and no more manual file zipping, complicated SVN commands, or missed steps. This streamlined approach saves you valuable time, reduces mistakes, and ensures every release is consistent and production-ready, so you can focus on innovation and serving your users.
Step 1: Set Up Your Unified GitHub Actions Workflow
Rather than maintaining multiple workflow files for standard releases and pre-releases, you can streamline everything with a single, unified deploy.yml file. This approach intelligently handles both production and pre-release builds, automatically detecting the release type based on your GitHub tag. With just one file, you simplify maintenance, reduce duplication, and make your deployment process more efficient and easy to manage.
Sample Automation Workflow File:
Place this file at .github/workflows/deploy.yml in the GitHub repo of your plugin’s project:
name: Build & Deploy WordPress Plugin
on:
release:
types: [released, prereleased]
env:
PLUGIN_SLUG: your-plugin-slug-here
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Install composer dependencies
uses: php-actions/composer@v2
with:
dev: no
- uses: actions/setup-node@v3
with:
node-version: '20'
- name: Install npm dependencies
run: |
npm ci
npm run build
- name: Generate plugin artifact
run: |
rsync -rc --exclude-from="$GITHUB_WORKSPACE/.distignore" "$GITHUB_WORKSPACE/" release/ --delete --delete-excluded
cd "${GITHUB_WORKSPACE}/release"
zip -r "${GITHUB_WORKSPACE}/${{ env.PLUGIN_SLUG }}.zip" .
- name: Upload release asset
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ github.event.release.upload_url }}
asset_path: ${{ github.workspace }}/${{ env.PLUGIN_SLUG }}.zip
asset_name: ${{ github.event.repository.name }}.zip
asset_content_type: application/zip
deploy:
needs: build
if: github.event.release.prerelease == false
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: WordPress Plugin Deploy
uses: 10up/action-wordpress-plugin-deploy@stable
with:
generate-zip: true
env:
SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
SLUG: ${{ env.PLUGIN_SLUG }}Key Points to understand:
- The workflow runs on both
releaseandprereleaseevents. - It builds your plugin and attaches a ready-to-download ZIP to the GitHub release.
- On production releases (not pre-releases), it automatically deploys to the WordPress.org SVN repo.
Step 2: Add Required Secrets to GitHub
To enable automated deployment, you need to securely store your credentials in GitHub so your workflow can access WordPress.org and manage releases.
- Go to your GitHub repository → Settings → Secrets and variables → Actions.
- Add these secrets:
SVN_USERNAME: Your WordPress.org username.SVN_PASSWORD: Your WordPress.org password (or, preferably, an application password for better security).
GitHub automatically provides the GITHUB_TOKEN for authenticating GitHub Actions, so you don’t need to add it manually. Storing your credentials as secrets ensures they are encrypted and never exposed in your workflow logs or code.
Step 3: Maintain a .distignore File
A .distignore file is critical for controlling which files are included in your plugin ZIP and deployed to WordPress.org. By excluding unnecessary files like build scripts, test directories, configuration files, and node_modules, you keep your releases clean and lightweight.
How to do it:
- Create a
.distignorefile in the root of your repository. - List all the files and directories you want to exclude from the final package.
Typical entries might include:
node_modules/
.git/
.github/
*.md
*.yml
composer.json
composer.lock
package.json
package-lock.json
webpack.config.jsPro Tip: Regularly review the WordPress Plugin Guidelines to ensure your
.distignorefile meets all requirements and doesn’t accidentally omit needed files.
Step 4: Tag and Release
Releasing a new version of your plugin is simple and intuitive:
- Draft a new release in GitHub and assign it a version tag (for example,
v1.2.0). - For alpha or beta versions, mark the release as a “pre-release” so your workflow handles it as a test build.
- For official production releases, simply publish as a normal release—no extra steps required.
This tagging approach keeps your release process standardized and easy for both solo developers and teams.
Step 5: The Workflow in Action
Once you create a release (or pre-release), the workflow springs into action:
- GitHub Actions checks out your code, installs Composer and npm dependencies, and runs any required build scripts.
- Your
.distignorerules are applied to ensure only production-ready files are included. - The plugin is zipped and attached to your GitHub release automatically, giving you a downloadable artifact for testing or distribution.
If it’s a production release, the workflow also deploys your plugin to the WordPress.org SVN repository, so users can update from their dashboards immediately.
Benefits
- You receive a ready-to-use, production-grade ZIP with every release.
- There’s no need to run manual SVN commands or handle packaging by hand.
- Your release process is reliable, repeatable, and completely hands-off.
Step 6: Pro Tips and Best Practices
- Always test the ZIP: Before announcing your release, download the ZIP from GitHub and install it on a local WordPress site to verify everything works as expected.
- Keep documentation up to date: Update your
readme.txtand changelog with clear notes on new features, fixes, and improvements before tagging a new release. - Automate quality checks: Integrate tools like PHPStan, PHPUnit, or ESLint into your workflow for better code quality and safer deployments.
- Explore advanced configurations: Review the 10up action documentation for options like branch-specific deployments, asset handling, or customizing your release pipeline to suit your project’s needs.
Ready to Modernize Your Plugin Releases?
Stop wasting hours on manual deployments and repetitive release tasks. Let automation handle your packaging and WordPress.org updates, so you can focus on growing your plugin and serving your users.
Frequently Asked Questions
Yes, but you’ll rarely need to. The workflow handles 99% of tasks.
Yes, this workflow only deploys to WordPress.org on production releases.
Rollback as usual on GitHub. For WordPress.org, you’ll need to update SVN or tag a new fixed version.
Set up multiple workflows, one per plugin folder/slug.
Conclusion
Automating your WordPress plugin packaging and deployment isn’t just about saving time—it’s about elevating your entire development process. By letting GitHub Actions handle repetitive build and release tasks, you gain confidence that every release is clean, consistent, and delivered at lightning speed. This automation reduces the risk of human error, ensures rapid delivery of bug fixes and security updates, and empowers everyone on your team or in your open-source community to contribute without fear of breaking the process.
Most importantly, a robust automated workflow means you spend less time worrying about deployments and more time building, innovating, and serving your users. Whether you manage one plugin or dozens, this approach sets you up for professional, scalable, and sustainable growth now and in the future.
