Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter leooelleo

    (@leooelleo)

    Update — I have found the cause, and it is not what my original report assumed. Summary: the malformed URL appears to be a downstream symptom of failed REST API discovery, not a URL-construction bug in isolation.

    First, to answer your suggestion: I toggled the Experimental Block Editor both on and off and retested. No change either way.

    What actually resolved it:

    My site runs the Restricted Site Access plugin, which blocks unauthenticated visitors. In the course of regenerating an Application Password I had to remove and re-add the site in the app — and at that point the app refused to add it at all, reporting “the site’s REST API is disabled.” It failed at the site-address step, before ever prompting for credentials, so this was not an authentication failure.

    I temporarily deactivated Restricted Site Access, added the site successfully, and immediately reactivated the plugin. Media uploads now work. I have uploaded several images without error, and the app continues to work with the plugin active again.

    Before (site added while Restricted Site Access was active):
    POST https://[my site]/wp-jsonwp/v2/media?_embed=wp%3Afeaturedmedia&_locale=user
    Response: 200 OK, Content-Type: text/html — the wp-login.php page, 8 KB of HTML
    The app then failed to parse that HTML as JSON, producing “The response is not a valid JSON response.”

    After (site re-added with the plugin temporarily off):
    POST https://[my site]/wp-json/wp/v2/posts/48251
    Response: 200 OK, valid JSON

    The path is now correctly formed. The missing slash is gone.

    My hypothesis — which you are far better placed to verify than I am — is that the app could not complete REST API discovery through the access restriction, and instead of failing loudly, fell back on a fabricated base URL, producing “wp-jsonwp/v2/…”. Once discovery completed cleanly, the correct base was cached, and that cached value survives the plugin being reactivated.

    If that is right, the substantive issue is not the malformed path itself but the silent degradation: when discovery fails, the app fabricates a URL and surfaces the problem three steps later as a misleading JSON parse error. A clear “could not reach the REST API at this address” would have saved a great deal of investigation, and would likely affect any self-hosted site behind an access-restriction or maintenance-mode plugin.

    One issue remains unresolved: the Media Library source button in the editor still does nothing when tapped — it neither opens the picker nor reports an error. Uploading a new photo works; browsing existing media does not. I am happy to investigate further if useful.

    Environment:

    • App: wp-iphone/27.0 (org.wordpress 27.0+27.0.0.1)
    • Device: iPad, iPadOS 26.5.2
    • Self-hosted WordPress 7.0.1, Application Password auth (not Jetpack/WordPress.com)
    • XML-RPC disabled
    • Restricted Site Access plugin active

    I have not attached the raw log export, as it contains the Authorization header in cleartext, but I can supply any specific fields you need.

    Thread Starter leooelleo

    (@leooelleo)

    Thanks for looking into this.

    I tried the first suggestion: I toggled “Experimental Block Editor” both on and off and retested in each state. No change — the upload fails identically either way.

    I then enabled Debug and Extensive Logging, reproduced the failure, and captured the request in the app’s network inspector. This gives an exact picture of what is going wrong:

    Request:
    POST https://[my site]/wp-jsonwp/v2/media?_embed=wp%3Afeaturedmedia&_locale=user
    Body: FormData, 1 field: file=

    The path is malformed. It should be:
    /wp-json/wp/v2/media

    There is a missing “/” between “wp-json” and “wp” — the REST base URL and the endpoint path appear to be concatenated without a separator.

    What happens next is the interesting part, and explains the misleading error message:

    Response: 200 OK
    Content-Type: text/html; charset=UTF-8
    Body: the WordPress wp-login.php login page (8 KB of HTML)

    Because /wp-jsonwp/v2/media is not a recognised REST route, WordPress does not 404 — it falls through and serves the login page with a 200 status. The app then attempts to parse that HTML as JSON, which fails, producing “The response is not a valid JSON response.”

    So the surface error is a JSON parse failure, but the actual defect is the malformed URL construction. Note also that the returned login form’s hidden redirect_to field contains the malformed path verbatim, confirming the server received it as sent.

    One difference from your test environment that may explain the non-reproduction: XML-RPC is disabled on my site. As a result the Posts section in the app carries a BETA label and appears to route into a newer CPT-based experience. If XML-RPC is enabled on your test site you may not be exercising the same code path. It may be worth retesting with XML-RPC disabled.

    Already ruled out:

    • Not file size (fails with a 1.7 MB JPEG; also tested 1.1–1.2 MB)
    • Not file format (plain JPEG, not HEIC)
    • Not server/host/firewall/security plugin — same site, same images, same device upload perfectly via Safari using the standard wp-admin block editor
    • Not authentication — credentials are sent and accepted; the Application Password was regenerated with no change; text-only publishing through the app works fine

    Environment:

    • App: wp-iphone/27.0 (org.wordpress 27.0+27.0.0.1)
    • Device: iPad, iPadOS 26.5.2
    • Self-hosted WordPress 7.0.1, connected via Application Password (not Jetpack/WordPress.com bridge)
    • XML-RPC disabled

    Happy to run further tests. I have not attached the raw log export as it contains the Authorization header in cleartext, but I can supply any specific fields you need.

    • This reply was modified 5 hours, 40 minutes ago by leooelleo.
Viewing 2 replies - 1 through 2 (of 2 total)