Bug: Articles addon runs one extra database query per listed article (N+1 layout queries)

Environment

• SP Page Builder Pro 6.9.1 (native Articles / Articles Slider addons)
• Joomla 5.4.9, PHP 8.3, MySQL 8.4
• Homepage with 6–7 Articles / Articles Slider blocks showing 6–20 articles each

The problem

In components/com_sppagebuilder/helpers/articles.php, getArticles() first loads the list of articles, then loops over them. Inside that loop, after the comment "Fetch layout data from SP Page Builder for this article", it builds and runs a separate query for every article in the list, loading that article's SP Page Builder layout (content, text, css) from #__sppagebuilder by extension = com_content, extension_view = article, view_id = <article id>, active = 1.

So an Articles block showing 10 articles runs 1 list query + 10 layout queries. On a homepage with 6–7 such blocks, that's dozens of extra queries per page view. Because SP Page Builder pages are not cached for logged-in users, every member page view repeats all of them.

On our site this was compounded by the missing index on #__sppagebuilder (separate report): each of those per-article queries was a full table scan of ~4,000 rows. Together this query shape was ~14–16% of our total database time.

Also worth noting: on our site only 107 of 4,013 article layout rows are active, so the vast majority of these per-article queries return nothing at all.

Suggested fix

1. Batch the lookup: after loading the article list, collect the article IDs and fetch all their layouts in one query (view_id in the list of IDs, plus the same extension / extension_view / active conditions), then attach each layout to its article in PHP.
2. Only load layouts when they are used: if the layout data is only needed for certain addon display options (for example dynamic content), skip the lookup entirely when the addon doesn't use it.
3. Combined with an index on (extension, extension_view, view_id), the per-block cost becomes one cheap indexed query instead of N full table scans.

Impact

The cost scales with the number of article blocks on a page × articles per block × page views by logged-in users. On busy membership or news sites, where many members load the same homepage at once, this adds a large and avoidable database load. The fix is local to one function and doesn't change any output.