Auto Categories Mapping becomes unresponsive with large category collections

Summary

The Auto Categories Mapping settings page becomes very slow and may time out when a site has a large category collection and multiple mapping rules. The page is expected to remain usable while creating and editing supported keyword mappings. Instead, loading and interacting with the mapping section can become impractical, preventing administrators from managing automatic category assignments.

Customer context

Product / area: Feedzy RSS Feeds Pro, Auto Categories Mapping settings UI
Version: Not provided by the reporter; defect is present in inspected Feedzy core v5.2.9
Environment: WordPress site hosted on a business hosting plan, with 57,765 categories
Integration / third party: Feedzy Pro Personal Yearly plan
Reported error / symptom: The settings page opens and loads mappings very slowly and sometimes times out when many auto-category rules are used
Impact: The administrator cannot reliably create or maintain a large set of automatic category mappings

Reproduction notes

1. Use Feedzy Pro on a WordPress site with a very large category collection; the reported site has 57,765 categories.
2. Open Feedzy > Settings > General and locate Auto Categories Mapping.
3. Create and save multiple keyword-to-category mapping rows.
4. Reload the settings page and observe page response time and browser responsiveness; the reporter observed very slow loading and intermittent timeouts.

Repository inspection confirms the multiplicative markup path, but no local runtime reproduction or exact mapping-row threshold was available.

Diagnosis

Conclusion

The current settings rendering path has a deterministic scalability defect matching the report. It retrieves the site's complete category collection and emits that complete option list inside each saved mapping row. With 57,765 categories, the rendered option count grows by 57,765 for every additional rule; client-side additions also clone a row containing the full option collection. This accounts for both server-response growth and browser unresponsiveness. The documented import-taxonomy limit does not constrain this separate settings query.

Where this likely occurs

• includes/layouts/settings.php — settings template, approx. lines 138–148: the General settings path obtains all non-empty and empty categories through get_categories() without a term count bound.
• includes/layouts/settings.php — Auto Categories Mapping renderer, approx. lines 189–215: each entry in $mapped_categories receives a <select> populated by iterating the complete $categories collection.
• js/feedzy-setting.js — initializeAutoCatActions() / getNewRow() approx. lines 103–155: adding a mapping deep-clones the first row, including its complete category option tree.
• includes/admin/feedzy-rss-feeds-import.php — Feedzy_Rss_Feeds_Import::get_taxonomies() approx. lines 1420–1444: the separate Import Post taxonomy selector applies feedzy_post_taxonomy_limit; this bound is not part of the Auto Categories Mapping settings path.
• Commit 78b6e421c42e6f65083e83536d0792cc73598441 introduced the unbounded mapping query and repeated option rendering. Tags containing it begin at v5.0.0 and continue through inspected v5.2.9. This identifies introduction, not a regression from a previously working release of the same feature.

Engineering notes

The settings UI is implemented in the free/core repository even though automatic mapping is exposed as a Pro capability. Saved rules are persisted by Feedzy_Rss_Feeds_Admin::save_settings() in includes/admin/feedzy-rss-feeds-admin.php approx. lines 1432–1480, while Pro consumes those rules during import. For the reported 57,765 categories, one rule produces at least 57,765 category options and ten saved rules produce at least 577,650 options before accounting for surrounding markup. The browser cost is compounded by deep-cloning this option tree for newly added rows. WordPress core internals were not present in the plugin checkout; the diagnosis relies on the plugin's explicit unbounded query and repeated template output rather than assumptions about core query internals.

Test coverage status

tests/e2e/specs/settings-save.spec.js covers persistence of a general settings toggle but does not exercise Auto Categories Mapping or large term collections. feedzy-rss-feeds-pro/tests/test-auto-map-categories.php covers keyword matching during import, not settings-page rendering or performance. No relevant large-taxonomy or multi-row UI coverage was found during inspection.

What to verify or explore next

• May be worth reproducing on v5.2.9 with category counts near 999, 25,000, and 57,765 and recording response size, server generation time, and browser interaction time as mapping rows increase.
• May be worth running the settings Playwright suite with multiple persisted mapping rows and a generated large category fixture.
• If reproducible, checking PHP memory and execution-time behavior separately from browser DOM and Select2 initialization costs could clarify each failure threshold.
• Compatibility checks across the supported WordPress and PHP versions may identify different practical limits.

Unknowns / follow-up

The reporter did not provide exact Feedzy, WordPress, PHP, browser, memory-limit, execution-time, or mapping-row counts. No local runtime benchmark was performed, so the precise timeout threshold remains environment-dependent.

Confidence

Confidence: 96/100

Current v5.2.9 source deterministically renders every WordPress category once per saved Auto Categories Mapping row, matching the reported slowdown and timeout at 57,765 categories; no existing open issue was found for this scalability defect. The separate 999-term import-selector behavior is a documented, configurable safety limit rather than a defect.

---

Source: HelpScout #3446381319
Generated by bug-report-triage (ID: bug-report-triage_6aa6d6ae55f563.72389377)