# WordPress Plugin SVN Guide – Short Reference
Prerequisites
- TortoiseSVN installed on Windows
- WordPress.org account with plugin approval
- Plugin files ready for upload
Initial Setup & First Upload
Step 1: Get Your SVN Repository URL
Your plugin’s SVN URL follows this format:
https://plugins.svn.wordpress.org/[your-plugin-name]/
Step 2: Initial SVN Checkout
- Create/navigate to your working folder
- Right-click → SVN Checkout
- URL:
https://plugins.svn.wordpress.org/[plugin-name]/ - Checkout Depth: Fully recursive, HEAD revision
- Enter WordPress.org credentials when prompted
This creates the standard structure:
assets/– Plugin directory images (banners, icons, screenshots)trunk/– Development versiontags/– Released versions
Step 3: Copy Your Files
Assets folder:
- Copy banner images, icons, screenshots to
assets/
Plugin code:
- Copy all plugin files to
trunk/
Step 4: Add Files to SVN
- Right-click main plugin folder → TortoiseSVN → Add
- Select all new files/folders → OK
- If “nothing to add” appears, check: Right-click → TortoiseSVN → Check for modifications
Step 5: Commit to Trunk
- Right-click main plugin folder → SVN Commit
- Commit message: “Initial plugin upload – version X.X.X”
- Ensure all files are checked → OK
Step 6: Create Version Tag
- Right-click
trunkfolder → TortoiseSVN → Branch/Tag - To path: Change from
/trunkto/tags/X.X.X - Create copy in repository from: HEAD revision in repository
- Log message: “Tagging version X.X.X”
- Click OK
Plugin Updates
For Assets Only (No Version Change)
Use case: Update banners, icons, screenshots without releasing new version
- Replace files in local
assets/folder - Right-click main plugin folder → SVN Commit
- Commit message: “Updated plugin assets”
- Click OK
Result: Changes appear immediately on plugin page, no user notifications
For Plugin Updates (New Version)
Use case: Code changes requiring new version
- Update version numbers in:
- Main plugin file header
readme.txtstable tag
- Modify code in
trunk/folder - Right-click main plugin folder → SVN Commit
- Commit message: “Update to version X.X.X”
- Click OK
- Right-click
trunkfolder → TortoiseSVN → Branch/Tag - To path:
/tags/X.X.X - Log message: “Tagging version X.X.X”
- Click OK
Result: Users get update notifications, new version available for download
File Structure Reference
your-plugin/
├── .svn/ (SVN metadata - don't touch)
├── assets/ (Plugin directory assets)
│ ├── banner-1544x500.png (Large banner)
│ ├── banner-772x250.png (Small banner)
│ ├── icon-128x128.png (Plugin icon - small)
│ ├── icon-256x256.png (Plugin icon - large)
│ ├── screenshot-1.png (Screenshots for plugin page)
│ └── screenshot-N.png (Up to 10 screenshots)
├── tags/ (Released versions)
│ ├── 1.0.0/ (Snapshot of version 1.0.0)
│ ├── 1.0.1/ (Snapshot of version 1.0.1)
│ └── X.X.X/ (Each tagged version)
└── trunk/ (Development/current version)
├── your-plugin.php (Main plugin file)
├── readme.txt (Plugin description/changelog)
├── assets/ (Plugin's internal assets)
├── includes/ (Plugin code files)
├── languages/ (Translation files)
└── uninstall.php (Cleanup code)
Important Notes
Version Numbers
- Plugin header: Must match readme.txt stable tag
- readme.txt: Update stable tag for each release
- Semantic versioning: Use X.Y.Z format (1.0.0, 1.0.1, 1.1.0)
Auto-Updates
- Plugins installed from WordPress.org get automatic update notifications
- Manually installed plugins may not receive updates unless headers match exactly
- Plan plugin structure for WordPress.org compatibility from the start
Common Commit Messages
"Initial plugin upload - version X.X.X""Update to version X.X.X""Updated plugin assets""Bug fixes for version X.X.X""Tagging version X.X.X"
Troubleshooting
- “Nothing to add”: Use “Check for modifications” to see file status
- Credentials: Use WordPress.org username/password
- Files not showing: Ensure proper file permissions and no .svnignore conflicts
- Tag creation fails: Ensure trunk is committed first
Quick Reference Commands
| Action | Steps |
|---|---|
| First upload | Checkout → Copy files → Add → Commit → Tag |
| Update assets | Replace files → Commit |
| Update plugin | Modify code → Update versions → Commit → Tag |
| Check status | Right-click → TortoiseSVN → Check for modifications |
For WordPress Compatibility Updates (No Code Changes)
Use case: Update “Tested up to” field without version bump
Option 1: Update Existing Tag (Recommended)
- Update locally: Change “Tested up to” in
readme.txt(keep same version) - Commit to trunk: Message: “Updated WordPress compatibility to 6.X.X”
- Update existing tag:
- Right-click trunk → TortoiseSVN → Branch/Tag
- To path:
/tags/X.X.X(same existing tag number) - Message: “Updated WordPress compatibility for X.X.X”
Result: Same version, updated compatibility, no user notifications
Option 2: New Version Tag
- Update locally: Change “Tested up to” and bump version number
- Commit and tag as normal plugin update
Result: New version, users get update notifications
Troubleshooting Common Issues
“Nothing to Add” Error
- Cause: Files already tracked or ignored
- Solution: Right-click → TortoiseSVN → Check for modifications
- Look for: Files with “?” (unversioned) status to add manually
Authentication Issues
- Use: WordPress.org username and password (not email)
- Reset: If forgotten, use WordPress.org password reset
- Cache: TortoiseSVN may cache credentials – clear if needed
Tag Already Exists Error
- Cause: Trying to create tag that already exists
- Solution: Delete existing tag first, or use different version number
- Alternative: Update existing tag (overwrites it)
Files Not Showing in Commit
- Check: File permissions and ownership
- Verify: No .svnignore or global ignore patterns blocking files
- Solution: Add files manually via “Add” dialog
Best Practices
- Test locally before committing to SVN
- Update version numbers before tagging (except compatibility updates)
- Write clear commit messages
- Keep assets optimized (reasonable file sizes)
- Validate readme.txt before upload
- Create tags for every release (enables rollbacks)
- Don’t commit unnecessary files (.DS_Store, node_modules, etc.)
- Regular compatibility updates keep plugin active in directory
- Use semantic versioning (X.Y.Z format consistently)
- Backup before major changes (though SVN provides history)
WordPress.org Timeline
- Assets: Update immediately
- Plugin approval: Initial review (varies)
- Updates: Available immediately after tagging
- Directory listing: Updates within hours
- Compatibility updates: Show immediately on plugin page