I recently placed a poll on the MainWP Facebook group about my future development for extensions and the question I was asking is there preferred client site deployment method for plugins where I can’t get the code for the child sites in that plugin i.e. by submission of a commit to the project.
The poll will run for sometime and while I prefer the single extension option I had a feeling the matched pair option would be the most popular.
This has left me with issues my deployment and release procedure is designed for single plugins to GitHub using UUPD, and this wouldn’t be suitable unless I am going to make two repositories for each and every extension which seems way to much work for me.
The real benefit of my current system is it uses pathed items to run and do a lot of the heavy lifting and reads a project specific cfg configuration for the project specific details its reusable and quick to deploy I wanted to keep this way of working.
The approach i’ve taken
A single sh script to run everything called build.sh this run’s asked you what type of build you want to do and the options are build individual plugins, prepare a suite release or build all plugin and the suite release i.e just updating the reality is i could make this a smidgen faster by removing this as 99.5% of the time except while building this I suspect I will pick number 3
This then call’s 2 new scripts based on the options selected which are plugin-build.sh and suite-release.sh and they load and run header changers and other information from my other posts here and if you check github and open any of my plugin there will be copies of deploy.sh and deploy.bat files in the repo to review
An example plugin.cfg is below
# Identity
PLUGIN_SLUG=mainwp-activity-log-ext
PLUGIN_NAME=MainWP Activity Log (activitylog.io) Extension
# Repo (for JSON download_url and raw assets)
GITHUB_OWNER=stingray82
GITHUB_REPO=mainwp-activity-log
RAW_BRANCH=main
# JSON author
AUTHOR_NAME=reallyusefulplugins.com
AUTHOR_URL=https://reallyusefulplugins.com
# Optional: prefix the JSON slug (usually leave empty)
JSON_SLUG_PREFIX=
# Use your external header updater (spaces in path are fine)
HEADER_SCRIPT=C:/Ignore By Avast/0. PATHED Items/Plugins/deployscripts/myplugin_headers.php
# ZIP name (defaults to <slug>.zip)
ZIP_NAME=mainwp-activity-log-ext.zip
# Optional: hint to main file (auto-detect if absent)
ENTRY_HINT=mainwp-activity-log-ext.php
# Optional header updates (if you’re not using an external PHP header tool)
# HEADER_VERSION=1.2.0
# HEADER_REQUIRES_AT_LEAST=6.5
# HEADER_TESTED_UP_TO=6.8.2
# HEADER_REQUIRES_PHP=8.0
# Optional: path to 7z if not on PATH (Windows example)
SEVENZIP=C:/Program Files/7-Zip/7z.exe
# Where JSON + content live
UUPD_DIR=uupd
# optional readme.txt inputs
CHANGELOG_FILE=C:\Users\Nathan\Git\rup-changelogs\mainwp-activity-log.txt
STATIC_FILE=static_ext.txt
PLUGIN_TAGS="mainwp, logs, audit"
CONTRIBUTOR="reallyusefulplugins"
DONATE_LINK="https://reallyusefulplugins.com/donate"
LICENSE_NAME="GPL-2.0-or-later"
LICENSE_URI="https://www.gnu.org/licenses/gpl-2.0.htmlan example suite.cfg is below
GITHUB_OWNER=stingray82
GITHUB_REPO=mainwp-activity-log
RAW_BRANCH=main
UUPD_DIR=uupd
# Fixed tag or dynamic:
SUITE_TAG=v$(date +%Y.%m.%d-%H%M)
# Markdown/HTML/TXT notes shown on GitHub release page:
SUITE_NOTES_FILE=uupd/suite-notes.md
# Slugs to upload (must match zip names <slug>.zip in repo root)
PLUGINS=(
"mainwp-activity-log-ext"
"mwalx-child-activity-log"
)
# optional git settings
PUSH_ALL=true # true => git add -A
PUSH_REMOTE=origin
PUSH_BRANCH=main # branch to push; defaults to RAW_BRANCHand this all cumulates into a new suite release which allows auto updating from these files all from a single repo and this should be entirely repeatable.
