fix(campaigns): show above-header prompts without JS delay (NPPM-2934)

[adekbadek]

All Submissions:

• Have you followed the Newspack Contributing guidelines?
• Does your code follow the WordPress coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Above-header Campaign Prompts were appearing only after a multi-second delay on sites running Perfmatters, because the Newspack Perfmatters defaults delay the prompt's view script until the reader's first interaction. The script reveals the prompt (it strips the server-rendered hidden class), so until it runs the prompt is invisible — hurting both visibility and CLS. Reported by CT Mirror and Outlier Media (NPPM-2934).

This PR:

1. Renders published above-header prompts immediately under Perfmatters. When the site has at least one published above-header prompt, the Perfmatters integration removes the reveal-path scripts (newspack-popups, window.newspack, newspack-plugin) from the JS delay queue and adds newspack-popups/newspack-plugin to the defer exclusions. Every other Newspack script stays delayed, so the rest of the site keeps the performance benefit. Detection is Newspack_Popups_Model::has_published_above_header_prompts() — transient-cached (the filter runs on essentially every front-end request) and invalidated when a prompt is saved, transitions status, has its placement meta changed, or is deleted.
2. Warns about the CLS tradeoff. A non-dismissible notice in the prompt editor (when placement is "Above site header") and in the Campaigns wizard (when a published above-header prompt exists) explains that above-header prompts shift layout as they load and suggests keeping them short or using an overlay.

The reveal-script set is intentionally minimal (only what gates the prompt becoming visible) rather than un-delaying all Newspack JS. Detection deliberately keys on published + above_header placement only, not full display eligibility (active campaign group / activation window / segment match) — replicating the Inserter's per-request logic on this hot path is too expensive, and the tradeoff is fail-safe: a published-but-never-shown prompt only forfeits the JS-delay optimization, it breaks nothing. This is documented at the detection method.

Closes NPPM-2934.

How to test the changes in this Pull Request:

1. On a site with Perfmatters active and the Newspack Perfmatters defaults applied, create and publish an above-header Campaign Prompt targeting the home page.
2. Load the home page in a fresh/incognito session. The prompt should appear immediately on load, not after a few seconds.
3. Confirm newspack-popups / window.newspack are no longer in Perfmatters' "Delay JavaScript" list and that newspack-popups / newspack-plugin are in the "Exclude from Delay/defer" set (or inspect via apply_filters( 'option_perfmatters_options', [] )).
4. Unpublish/trash the above-header prompt and reload: the scripts return to the delay queue (other Newspack scripts were delayed throughout).
5. In the prompt editor, set placement to "Above site header" → a CLS warning notice appears under the placement control; switch away → it disappears.
6. In Audience → Campaigns, the same warning appears at the top while a published above-header prompt exists.

Note: on Atomic/WPCloud, already-cached pages keep the old script config until their own page-cache entries purge/expire.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable? (AboveHeaderDetectionTest in newspack-popups; Newspack_Test_Perfmatters in newspack-plugin.)
• Have you successfully run tests with your changes locally? (Full newspack-popups suite green; new perfmatters tests green; browser-verified on an isolated env.)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.