v1.17.2 on WordPress.org still contains HTTP 200-only check in fetchExternalData() — fix exists in repo but not released

[ingnrcs]

The fix for fetchExternalData() accepting only HTTP 200 from hub-api.h5p.org already exists in the repository, but has not been included in the latest release (v1.17.2) distributed through WordPress.org. As a result, any fresh installation of H5P from WordPress.org is broken out of the box — site registration fails silently on every new install.

---

What the current released version (v1.17.2) has:

// public/class-h5p-wordpress.php
elseif ($response['response']['code'] === 200) {
    return empty($response['body']) ? TRUE : $response['body'];
}
return NULL; // HTTP 201 falls here → returns NULL → treated as failure

What the repository (main branch) already has:

elseif ($response['response']['code'] >= 200 && $response['response']['code'] < 300) {
    return empty($response['body']) ? TRUE : $response['body'];
}
return NULL;

The repository version correctly accepts any 2xx response. The released version does not.

---

Impact

hub-api.h5p.org/v1/sites now returns HTTP 201 Created for new site registrations. Because the released plugin only accepts 200, the registration flow fails on every new install:

1. Plugin POSTs to hub-api.h5p.org/v1/sites
2. Server responds HTTP 201 + {"uuid": "..."}
3. fetchExternalData() returns NULL (201 not handled)
4. fetchLibrariesMetadata() evaluates if (!$registration) → enters error block
5. Error message displayed: "Site could not be registered with the hub"
6. UUID never saved → cycle repeats on every admin page load, generating a new UUID each time

---

Evidence

Debug log from a live affected site (H5P v1.17.2, WordPress 6.9.1, Hostinger):

H5P INTERNAL REQUEST URL: https://hub-api.h5p.org/v1/sites
H5P INTERNAL REQUEST BODY: Array ( [uuid] =>  [platform_name] => WordPress ... )
H5P INTERNAL RESPONSE CODE: 201
H5P INTERNAL RESPONSE BODY: {"uuid":"019cd7a5-a224-703e-b03d-d1321aec2cc6"}

// Next request — uuid is still empty because it was never saved:
H5P INTERNAL REQUEST BODY: Array ( [uuid] =>  [platform_name] => WordPress ... )
H5P INTERNAL RESPONSE CODE: 201
H5P INTERNAL RESPONSE BODY: {"uuid":"019cd7a5-def7-7238-84b7-3e3c0e7c7f0e"}

A new UUID is generated on each request because the previous one is never persisted — confirmed across 20+ registration attempts in the same session.

---

Workaround (applied manually on affected site)

Manually patching the released file with the fix already present in the repo resolves the issue immediately:

// Change this:
elseif ($response['response']['code'] === 200) {
// To this:
elseif ($response['response']['code'] >= 200 && $response['response']['code'] < 300) {

---

Request

Please publish a new release to WordPress.org that includes the fix already present in the main branch. This is actively breaking H5P for all new installs and the fix is already done — it just needs to be shipped.

---

Plugin version tested: 1.17.2 (from WordPress.org)
WordPress version: 6.9.1
PHP: 8.x
Hosting: Hostinger

[otacke]

@ingnrcs H5P Group will release another update with more fixes shortly.