Feedzy shortcode can block page rendering for up to 300 seconds per feed request

Summary

A page containing a non-lazy Feedzy shortcode can remain pending for an extended period when its configured feed is slow or unreachable. The page is expected to finish rendering within a bounded frontend response time and present an error or fallback when feed retrieval fails. Instead, the page request can wait for up to 300 seconds for a feed request, with additional waits possible during recovery attempts or when several feeds are configured. This makes affected pages appear to hang and can render them unusable during feed connectivity problems.

Customer context

Product / area: Feedzy RSS Feeds Lite shortcode rendering
Version: 5.2.8
Environment: WordPress site; hosting and PHP details were not provided
Integration / third party: External RSS feed endpoint; URL and endpoint condition were not provided
Reported error / symptom: A page hangs when the shortcode is used
Impact: The plugin was deactivated after the shortcode page became unresponsive

Reproduction notes

Reported reproduction:

1. Use Feedzy RSS Feeds Lite 5.2.8.
2. Place a Feedzy shortcode on a page.
3. Visit the page.
4. Observe that the page hangs.

Code-confirmed condition: a non-lazy shortcode with an uncached slow or unreachable feed performs synchronous retrieval with a 300-second per-request timeout. Runtime reproduction was not performed because the original feed URL and environment were not provided.

Diagnosis

Conclusion

The inspected shortcode path performs feed retrieval synchronously during frontend page generation and configures the associated WordPress HTTP requests with a 300-second timeout. This directly permits a slow or unreachable feed to hold the page response for approximately five minutes per request. The customer did not provide a feed URL or trace, so the exact network trigger is unknown, but the blocking product behavior is confirmed in code.

Where this likely occurs

• includes/feedzy-rss-feeds.php — Feedzy_Rss_Feeds::define_admin_hooks() line 215 registers [feedzy-rss] to the frontend handler.
• includes/abstract/feedzy-rss-feeds-admin-abstract.php — Feedzy_Rss_Feeds_Admin_Abstract::feedzy_rss() lines 423–533; the non-lazy path calls fetch_feed() at line 526 and does not render content until retrieval returns.
• includes/abstract/feedzy-rss-feeds-admin-abstract.php — Feedzy_Rss_Feeds_Admin_Abstract::fetch_feed() lines 796–849 and init_single_feed() lines 896–949; request setup precedes the blocking SimplePie initialization at line 920.
• includes/admin/feedzy-rss-feeds-admin.php — Feedzy_Rss_Feeds_Admin::pre_http_setup() lines 1555–1566 attaches the request-argument filter, and http_request_args() lines 1866–1874 sets the timeout to 300 seconds.
• includes/abstract/feedzy-rss-feeds-admin-abstract.php — Feedzy_Rss_Feeds_Admin_Abstract::init_multiple_feeds() lines 966–1044 fetches multiple feeds sequentially, allowing per-request waits to accumulate.
• includes/abstract/feedzy-rss-feeds-admin-abstract.php — Feedzy_Rss_Feeds_Admin_Abstract::handle_feed_error() lines 1225–1291 can perform an additional synchronous request at line 1263 after a feed error.
• Commit 9b4b831041eeb2e1151f3815a526c2456d195dba introduced the 300-second timeout in 2022 and is contained in releases from v3.8.2 through v5.2.8. No changes to the inspected shortcode or HTTP setup files were present between v5.2.7 and v5.2.8.

Engineering notes

The default non-lazy shortcode branch blocks the originating PHP request. The timeout is applied per HTTP request rather than as an aggregate shortcode budget. Multiple feed URLs are processed serially, and error recovery can initiate further requests, so total elapsed time can exceed 300 seconds. The repository confirms these data-flow properties but does not identify whether the reported site encountered DNS delay, connection failure, TLS behavior, a slow response, or another endpoint condition. The WordPress HTTP transport internals were not present in the inspected plugin checkout and were not treated as locally verified.

Test coverage status

tests/test-shortcode-render.php lines 35–120 intercept HTTP requests with Test_Feedzy_Shortcode_Render::mock_http_request(), returning fixtures or immediate errors. Its shortcode tests at lines 145–290 cover registration and rendered output but do not exercise slow responses, connection timeouts, cumulative multi-feed waits, or recovery-request duration. No relevant timeout coverage was found during inspection.

What to verify or explore next

• May be worth reproducing with an uncached non-lazy shortcode whose test endpoint delays beyond the normal frontend response budget.
• May be worth measuring one unreachable feed and several sequential unreachable feeds separately.
• If reproducible, checking the SSL-error and malformed-feed recovery paths would establish whether additional requests extend the wait.
• Running the shortcode PHPUnit suite alongside a controlled HTTP integration test would confirm existing rendering behavior and elapsed-time boundaries.

Unknowns / follow-up

The submitted shortcode attributes, number of feeds, feed URL, cache state, server timeout settings, and PHP or web-server logs are unavailable. The report does not establish whether the browser eventually received an error or whether infrastructure terminated the PHP request first.

Confidence

Confidence: 92/100

Repository inspection confirms that the normal shortcode path performs remote feed retrieval inside the frontend request with a 300-second per-request timeout; the sparse report is consistent with this behavior, and no matching GitHub issue was found.

---

Source: automated uninstall feedback — feedzy-rss-feeds, 2026-08-31
Generated by bug-report-triage (ID: bug-report-triage_6a965c1bd3a0c0.06068074)

Start with the non-lazy shortcode path in includes/abstract/feedzy-rss-feeds-admin-abstract.php, then inspect pre_http_setup() and http_request_args() in includes/admin/feedzy-rss-feeds-admin.php. Review tests/test-shortcode-render.php and add controlled coverage for slow or unreachable feeds, multiple feeds, and recovery requests. Done means frontend rendering remains within a bounded response time while preserving the existing error or fallback behavior.