fix: lazy feed loader remains on Loading... after request failure

[Alexia-Soare]

A [feedzy-rss] shortcode with lazy='yes' left visitors on an indefinite "Loading..." whenever the request fetching the feed content failed — a dropped connection, an HTTP error, or a response the handler couldn't parse. The lazy loader now always exits the loading state: it renders the feed on success and shows an error message on any failure. Reported in issue #1299, originally from HelpScout conversation 3402495948.

What changed

• Lazy loader (js/feedzy-lazy.js) — failed requests now replace "Loading..." with a localized "The feed could not be loaded." message. Before → after: stuck loader forever → error message about one second after the failure.

• Response handling — HTTP 200 responses without usable content no longer strand or blank the container: wp_send_json_error() envelopes show the server's message, raw string returns from the REST callback are rendered as-is, and a success:true payload missing data.content falls back to the error message.

• Error message (feedzy-rss-feeds-admin-abstract.php) — the message is translatable and filterable via a new feedzy_lazyload_error_msg filter, mirroring the existing feedzy_lazyload_loading_msg filter for the loading text.

Lazy load flow

flowchart LR
    A[Page renders<br/>lazy shortcode] --> B{Cached<br/>content?}
    B -- Yes --> C[Feed shown<br/>immediately]
    B -- No --> D["Loading... +<br/>request to<br/>/feedzy/v1/lazy"]
    D --> E{Changed:<br/>response has<br/>rendered content?}:::changed
    E -- Yes --> F[Feed items shown]
    E -- "No, server sent<br/>a message" --> G[New:<br/>show server message]:::added
    E -- "No, request failed<br/>or malformed" --> H[New:<br/>show error message]:::added

    classDef added fill:#1a7f37,color:#fff,stroke:#116329,stroke-width:3px
    classDef changed fill:#9a6700,color:#fff,stroke:#5c3d00,stroke-width:3px,stroke-dasharray:6 3

Loading

QA

1. In WP Admin → Posts → Add New Post, insert a Shortcode block (the generic core block, not the Feedzy block — the Feedzy block intentionally skips lazy loading) containing:

   [feedzy-rss feeds='https://s3.amazonaws.com/verti-utils/sample-feed.xml' max='3' lazy='yes']
   

   Publish and view the post.
   Expect: "Loading..." appears briefly, then the feed items render.
2. Edit the post and change max to a value not used before (each successful load caches the rendered feed per attribute set, so a fresh value forces the loading state). Update the post. On the post's frontend page, open DevTools → Network, filter by lazy, reload once, right-click the lazy/ fetch request (not the feedzy-lazy.js script) → Block request URL. Change max again, update, and reload the post.
   Expect: "Loading..." switches to "The feed could not be loaded." about one second after the blocked request appears — previously it stayed on "Loading..." indefinitely.
3. Remove the blocking pattern and reload the post with one more fresh max value.
   Expect: the feed loads normally again.

🤖 Generated with Claude Code

[pirate-bot]

Plugin build for aeeddf3 is ready 🛎️!

• Download build

Note

You can preview the changes in the Playground

[Copilot]

Pull request overview

Fixes lazy shortcode loaders remaining indefinitely in a loading state after failed or malformed requests.

Changes:

• Adds fallback handling for transport and malformed-response failures.
• Introduces a localized, filterable error message.
• Adds E2E coverage for lazy-load failure scenarios.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
js/feedzy-lazy.js	Handles unsuccessful and unexpected AJAX responses.
includes/abstract/feedzy-rss-feeds-admin-abstract.php	Provides the localized lazy-load error message.
tests/e2e/specs/import.spec.js	Tests lazy-load response failure paths.

Comments suppressed due to low confidence (2)

tests/e2e/specs/import.spec.js:165

• This starts waiting after navigation and after asserting the transient loading text. If the one-second timer fires before those operations finish, the request event is missed and this test times out despite correct behavior. Register the request promise before goto() and avoid requiring the transient text to remain visible.

		await expect(lazyContainer).toContainText('Loading');
		await page.waitForRequest(/feedzy\/v\d+\/lazy/);

tests/e2e/specs/import.spec.js:190

• All four tests using this helper can race the loader: waitForRequest() is registered after goto() and a Loading assertion, while the request starts on a one-second timer. On a slow navigation the event and loading state can already be gone, producing flaky failures. Arm the request wait before navigation and then assert only the stable final state.

	async function expectLazyResult(page, postId, expectedText) {
		await page.goto(`/?p=${postId}`);
		const lazyContainer = page.locator('.feedzy-lazy');
		await expect(lazyContainer).toContainText('Loading');
		await page.waitForRequest(/feedzy\/v\d+\/lazy/);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[selul]

@Alexia-Soare lets reuse the strings here #1301 (comment)

[Alexia-Soare]

@Alexia-Soare lets reuse the strings here #1301 (comment)

Done