Repository navigation
Rename upgrade checks
phpbb-test-board/rename_upgrade.py path/to/extension@OLD_REF path/to/extension[@REF] [--setting NAME=VALUE]For an extension that moved to a new composer name and PHP namespace, for example rmcgirr83/stopforumspam to phpbbmodders/stopforumspam. phpBB records migrations by class name, so without help it treats the renamed extension as new and runs every migration again, which resets its settings. The renamed version's ext.php has to move the old records over first; this script checks that it does.
It installs the old version, then upgrades the way an admin would: the new version must refuse to enable while the old one is enabled, then the old one is disabled, the new one enabled and the old files deleted. It then checks that:
- the migration history moved to the new name and kept its original timestamps, so nothing ran again;
- no migration name or dependency, ACP module, notification type or setting name still uses the old name;
- there are no duplicate ACP modules, and the old extension's record is gone;
- every setting the old version added is still there, and
--setting(changed before the upgrade) kept its value; - the board index, a topic and the extension's ACP pages load with no PHP errors.
For example, Stop Forum Spam from its last rmcgirr83 release:
phpbb-test-board/rename_upgrade.py path/to/stopforumspam@0af40a1 path/to/stopforumspam \
--setting sfs_api_key=UPGRADE-TEST| Argument/option | Behavior |
|---|---|
OLD_REPO@REF |
Old checkout and explicitly selected historical ref. |
NEW_REPO[@REF] |
Renamed checkout, default HEAD. |
-s, --setting NAME=VALUE
|
Change one old setting and verify it survives. This is a single option value, not a repeatable list. |
-w, --with PATH[@REF]
|
Repeatable shared dependency, enabled first. |
-b, --board-dir DIR
|
Explicit disposable board. |
-p, --port PORT
|
Temporary server port, default 8083. |
-h, --help
|
Usage. |
The old and new refs may be in the same repository. Use synthetic test settings rather than real API credentials. This performs a migration test on the disposable board; it does not migrate a production installation. A passing scenario covers the supplied old/new pair and selected setting, not every historical upgrade path.
- Home
- Installation
- Release workflows
- Extension releases
- Style releases
- Language pack releases
- Default branch releases
- GitHub releases and recovery
- Test board setup
- Smoke and feature checks
- Unit tests and PHP lint
- Screenshots
- Rename upgrade checks
- Template accessibility
- Forum update posts
- Waiting for PR checks
- Troubleshooting
- Maintainer checks