ranger/rangerhq-radio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.7.4 — wp.org submission cleanup: remove updater + add LICENSE

Browse Source 
Walks back v0.7.3's Update URI guard pattern. Plugin Check raised
`plugin_updater_detected` on the v0.7.3 build:

    "Including An Update Checker / Changing Updates functionality.
     Plugin Updater detected. Use of the Update URI header is not
     allowed in plugins hosted on WordPress.org."

PCP scans the source as-shipped, not as-distributed, so the v0.7.3
build-time `sed` strip never had a chance to run before the scan.
The simpler correct answer is to delete the custom updater entirely
and rely on wp.org as the canonical update channel once accepted.

Removed:
* `inc/updater.php` — recoverable from git history at tag v0.7.3 if
  ever needed for a non-wp.org distribution.
* `Update URI:` header line in `radio.php` (plus the NOTE block).
* `require_once RADIO_PATH . 'inc/updater.php';` in `radio.php`.
* Updates panel render + `function_exists()` guard in `inc/settings.php`.
* "Self-hosted update checker" line in `README.md`.
* "Self-hosted updater" bullet in `readme.txt` Privacy section.

Added (GPL declaration loop closed):
* `LICENSE` — verbatim canonical GPL v2 text (338 lines from
  gnu.org/licenses/gpl-2.0.txt).
* GPL header block in `assets/css/radio.css`.
* GPL header block in `assets/js/radio.js` (original module overview
  preserved verbatim below the license header).
* GPL header block in `radio.php` docblock alongside the existing
  `License:` / `License URI:` fields.

Migration: existing Gitea-installed copies of v0.7.3 or earlier
become orphaned of auto-updates after this lands on them (the
updater code is gone, so nothing advertises newer versions back).
Recommended path is to uninstall + reinstall from wp.org once the
plugin is accepted. No data loss — station + volume + theme +
history + favourites all live in user_meta.

No user-visible behaviour changes for the player itself. Only the
small `Updates` panel that sat at the bottom of Radio → Settings
is gone.
This commit is contained in:
David Keane
2026-05-30 04:43:16 +01:00
parent a9d76decae
commit de93aa50ca
10 changed files with 417 additions and 314 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+35
View File
@@ -9,6 +9,41 @@ Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versi
---
## [0.7.4] — 2026-05-30 — WordPress.org submission cleanup (updater out, LICENSE in)
Walks back the Update URI guard pattern from v0.7.3 and replaces it with the simpler, actually-correct answer: just remove the custom updater entirely. The WordPress.org Plugin Check tool (PCP) raised `plugin_updater_detected` on the v0.7.3 build with the message *"Including An Update Checker / Changing Updates functionality. Plugin Updater detected. Use of the Update URI header is not allowed in plugins hosted on WordPress.org."* PCP scans the source as-shipped, not as-distributed, so the build-time `sed` strip we relied on in v0.7.3 never had a chance to run before the scan — and the scanner flagged both the header and the `inc/updater.php` file itself. Two options remained: (a) keep dancing around PCP with branches and build scripts, or (b) accept that WordPress.org is the canonical update channel once a plugin is hosted there and drop the custom system. We went with (b).
This release also closes the per-file GPL declaration loop by adding a top-level LICENSE file with the full GPL v2 text and explicit GPL header blocks to the CSS and JS assets — every shipped file now declares its license unambiguously.
### Removed
- **`inc/updater.php`** — the self-hosted Gitea updater. Deleted from the working tree (still recoverable from git history at tag `v0.7.3` if ever needed for a non-wp.org distribution). With the file gone, PCP's `plugin_updater_detected` check is silent.
- **`Update URI:` header** in `radio.php`. PCP forbids the header in wp.org-hosted plugins, even when its value would legitimately defer updates to wp.org. (The v0.7.3 NOTE block in the file header documenting the strip-on-package pattern was removed along with it.)
- **`require_once RADIO_PATH . 'inc/updater.php';`** line in `radio.php`. The file no longer exists, so no require is needed.
- **Updates panel render block + `function_exists()` guard** in `inc/settings.php`. The panel function no longer exists in any build, so the call site is gone. Settings page now ends cleanly at the *Save Changes* button.
- **"Self-hosted update checker against the Gitea repo"** bullet in the top-level `README.md`. Replaced with *"Updates via WordPress.org (the canonical channel once published)"*.
- **"Self-hosted updater" bullet** in the `readme.txt` Privacy section. Replaced with a positive statement that updates come from WordPress.org through the normal core update process.
### Added
- **`LICENSE` file** at the plugin root — verbatim canonical GPL v2 text from `https://www.gnu.org/licenses/gpl-2.0.txt`, 338 lines. The plugin header has always declared GPL v2+ but wp.org reviewers like to see the full text shipped alongside.
- **GPL header block in `assets/css/radio.css`** (Copyright, GPL v2+ grant, pointer to LICENSE) so the CSS file's licensing is explicit at the file level, not inferred from the plugin header.
- **GPL header block in `assets/js/radio.js`** — same treatment as the CSS. The original `/** Radio — vanilla JS audio controller. */` opening is preserved verbatim as the "module overview" section below the license header.
- **GPL header block in `radio.php`'s docblock** — Copyright line + GPL v2+ grant + LICENSE pointer added below the `@package` tag. Sits alongside the existing `License:` / `License URI:` header fields rather than replacing them.
### Changed
- **`readme.txt` Stable tag** → `0.7.4`.
- **`inc/about.php` Version history** — v0.7.4 rotated into the "latest" slot; v0.7.3 demoted to a one-liner in the earlier-releases list with a note explaining the walkback.
- **`RADIO_GITEA_URL` constant** is kept in `radio.php`. It's no longer used by an updater, but `inc/about.php` still uses it to render the *"View the full CHANGELOG.md →"* outbound link on the About page. Linking to a self-hosted source repo as a documentation reference is not the same as running a custom updater — that's fine in wp.org-hosted plugins. ([WordPress.org allows links to external source repos](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/) — the prohibition is on the update *mechanism*, not on referring to where the source lives.)
### Migration
- **Existing wp.org installs** (post-acceptance): WordPress core handles updates automatically. Nothing to do.
- **Existing Gitea-installed copies of v0.7.3 or earlier** (e.g. M5): the `inc/updater.php` file on disk will become orphaned after this update lands on them — it's no longer required from `radio.php`, so it just sits there as a dormant file until the next reinstall. **Recommended path for those installs:** once a-radio is accepted onto WordPress.org, uninstall the Gitea-sourced copy and reinstall from WordPress.org. Future updates then flow through wp.org. Until acceptance, those installs simply stop receiving updates (the v0.7.3 updater code is gone in v0.7.4, so there's nothing to advertise newer versions back to them).
- **No data loss** in any case: station + volume + theme + history + favourites all live in `user_meta` and survive uninstall/reinstall cycles.
### Why this is the right answer (and v0.7.3 was clever but wrong)
v0.7.3's Update URI guard pattern reasoned correctly about WordPress core's behaviour — the `Update URI` header genuinely does opt a plugin out of wp.org's update channel, and the runtime guard genuinely would short-circuit the updater on stripped builds. But the whole scheme assumed the reviewer would see the *stripped* build. The Plugin Check tool runs against the *source* artifact — the same source that's in the public repository, that future contributors clone, that automated audits scan. From PCP's point of view, the plugin was "shipping" an updater regardless of what the build script did with it later. The simpler answer (just delete the updater for the wp.org branch) sidesteps that entire class of "the static scanner doesn't know about your build pipeline" problem.
---
## [0.7.3] — 2026-05-30 — WordPress.org guideline 8 compliance + Privacy section
WordPress.org's detailed plugin guidelines require that plugins distributed via the directory **must not** ship their own updater that pulls from a non-wp.org server (guideline 8). RangerHQ Radio's self-hosted Gitea updater predates the wp.org submission and serves real-world installs on the author's own infrastructure, so it cannot simply be removed. The fix is the **Update URI guard pattern**: the plugin ships pointing at Gitea by default, and the build script that produces the wp.org submission zip strips the `Update URI:` header line. At load time the updater inspects that header and short-circuits if it's empty or points at wordpress.org.