DP-48482: Update PHP to 8.4

[tfleming-ma]

Description:
Updated to PHP 8.4

Jira: (Skip unless you are MA staff)
DP-48482

To Test:

• Review list of upgraded modules listed in ticket comments
• Also review updated packages found in this PR
• Check deployed feature environment for correct PHP version (can be seen at admin/reports/status/php)
• Run tests
• Smoke tests

---

Peer Review Checklist

[github-actions]

Composer package changes

Prod Packages (42 packages)

Prod Packages	Operation	Base	Target
dompdf/php-font-lib	Upgraded	1.0.1	1.0.2
drupal/access_unpublished	Upgraded	1.6.0	1.7.0
drupal/config_ignore	Upgraded	3.3.0	3.4.0
drupal/ctools	Upgraded	4.1.0	4.1.1
drupal/devel	Upgraded	5.3.1	5.5.0
drupal/externalauth	Upgraded	2.0.9	2.0.13
drupal/file_mdm	Upgraded	3.1.0	3.2.0
drupal/flag	Upgraded	4.0.0-beta5	5.1.0-beta2
drupal/key_auth	Upgraded	2.2.0	2.2.3
drupal/layout_paragraphs	Upgraded	2.1.1	2.1.3
drupal/openid_connect	Upgraded	3.0.0-alpha6	3.0.0-alpha8
drupal/openid_connect_windows_aad	Upgraded	2.0.0-beta9	2.0.0-beta10
drupal/paragraphs	Upgraded	1.21.0	1.23.0
drupal/purge	Upgraded	3.6.0	3.7.0
drupal/reference_blocked_users	Upgraded	1.0.5	2.0.0-rc1
drupal/scheduled_transitions	Upgraded	2.7.0	2.8.4
fileeye/pel	Upgraded	0.10.0	0.12.1
guzzlehttp/promises	Upgraded	2.5.1	2.5.3
lcobucci/jwt	Upgraded	5.3.0	5.6.0
mck89/peast	Upgraded	v1.17.6	v1.17.7
pear/archive_tar	Upgraded	1.6.0	1.6.1
symfony/console	Upgraded	v7.4.14	v7.4.17
symfony/dependency-injection	Upgraded	v7.4.14	v7.4.17
symfony/dom-crawler	Upgraded	v7.4.12	v7.4.17
symfony/error-handler	Upgraded	v7.4.14	v7.4.17
symfony/event-dispatcher	Upgraded	v7.4.14	v7.4.17
symfony/filesystem	Upgraded	v7.4.11	v7.4.17
symfony/finder	Upgraded	v7.4.14	v7.4.17
symfony/http-client	Upgraded	v7.4.14	v7.4.17
symfony/http-foundation	Upgraded	v7.4.14	v7.4.17
symfony/http-kernel	Upgraded	v7.4.14	v7.4.17
symfony/mailer	Upgraded	v7.4.14	v7.4.17
symfony/mime	Upgraded	v7.4.13	v7.4.17
symfony/polyfill-php83	Upgraded	v1.38.2	v1.41.0
symfony/process	Upgraded	v7.4.13	v7.4.17
symfony/routing	Upgraded	v7.4.13	v7.4.17
symfony/serializer	Upgraded	v7.4.14	v7.4.17
symfony/string	Upgraded	v7.4.13	v7.4.15
symfony/validator	Upgraded	v7.4.14	v7.4.17
symfony/var-dumper	Upgraded	v7.4.14	v7.4.17
symfony/var-exporter	Upgraded	v7.4.14	v7.4.16
symfony/yaml	Upgraded	v7.4.14	v7.4.17

Dev Packages (5 packages)

Dev Packages	Operation	Base	Target
doctrine/instantiator	Upgraded	2.0.0	2.1.0
justinrainbow/json-schema	Upgraded	6.10.0	6.11.0
myclabs/deep-copy	Upgraded	1.13.4	1.14.0
symfony/browser-kit	Upgraded	v7.4.14	v7.4.17
symfony/css-selector	Upgraded	v7.4.9	v7.4.17

[dstorozhuk]

@tfleming-ma please pin to 8.4 here. Right now it allow ant 8.x version. 4.70.7 is wodby version of their container, and it can be the same for 8.3, 8.4

[dstorozhuk]

Blocker: the Rabbit Hole 1.x → 2.x upgrade drops every per-node override

After deploying this branch, Person pages that are published through a per-node Rabbit Hole override start returning 404. In my sanitized copy that is 367 published person nodes (the person bundle default is page_not_found, so those pages are reachable only because of the override).

Why

Rabbit Hole 2.x reads the per-entity override only from the new rabbit_hole__settings field. The legacy rh_action base field still exists — rh_node / rh_taxonomy stay enabled — but BehaviorSettingsManager::getEntityBehaviorSettings() never looks at it.

That field is created by rabbit_hole_update_8104, which only acts on bundles whose stored settings still carry allow_override. This branch already ships rabbit_hole.behavior_settings.* in the 2.x format, where that key no longer exists — so the hook creates nothing, and rabbit_hole_update_8106 then reports "There are no entities to be updated" and marks itself complete.

Nothing errors and drush config:status stays clean, because the field is absent from both the active store and the sync directory. The data is still in rh_action; it is just never read again.

The issue

Must be 200, because has overrides:

• https://www.mass.gov/person/john-kates-director-of-property-operations
• https://www.mass.gov/person/sean-foley-director-of-facility-resources
• https://www.mass.gov/person/regie-gibson-poet-laureate
• https://www.mass.gov/person/allison-lamey-deputy-commissioner-office-of-finance-and-administration

But, locally on feature/DP-48482_php-8-4-upgrade after composer i, drush deploy all 404.

• https://mass.local/person/john-kates-director-of-property-operations
• https://mass.local/person/sean-foley-director-of-facility-resources
• https://mass.local/person/regie-gibson-poet-laureate
• https://mass.local/person/allison-lamey-deputy-commissioner-office-of-finance-and-administration

No override — 404 on prod and local on the on feature/DP-48482_php-8-4-upgrade:

• https://www.mass.gov/person/eric-batista
• https://www.mass.gov/person/karen-guthrie-magistrate

The fix

1. Go to https://mass.local/admin/config/content/rabbit-hole/node
2. Find Person
3. Set «Allow these settings to be overridden for individual entities» and save. (BTW this actions will create needed configs and fields)
4. On the Person page you will now see field RH settings, and you can set to "Display Page"

What the fix needs

Two things, and exporting the config alone is not enough — I tried that first and the field comes back empty (0 rows), because rabbit_hole_update_8106 is already marked as run and would find nothing even if replayed:

1. Commit the field config: field.storage.{node,taxonomy_term}.rabbit_hole__settings, the field.field.*.rabbit_hole__settings instances for the bundles that allowed an override, and the form/view displays that carry the widget.
2. Add a deploy hook that copies rh_action (plus the redirect settings, for page_redirect) onto rabbit_hole__settings. It runs after config import, so the field exists by then.

With both in place the branch matches the develop baseline exactly: the override pages are 200 again, the others stay 404, and config:status is clean.

Both are in #3493, which targets this branch. With them applied the branch matches the develop baseline exactly.

[dstorozhuk]

Re-reviewed after the rabbit_hole revert. The 404 blocker is gone (rabbit_hole back to 1.1.0, configs identical to develop, only the nullable patch remains). Three things left before merge, the first is a one-line fix.

1. openid_connect.client.azure_ad.yml is missing settings.prompt, so editors get prompt=login (forced Azure re-auth) on every SSO login.
In openid_connect alpha8 OpenIDConnectClientBase::defaultConfiguration() returns prompt: ['login'] (line 202) and setConfiguration() merges defaults into stored config, so a missing key resolves to login, and lines 347-348 append it to the authorize URL. WindowsAad::defaultConfiguration() inherits that default. The module handles this in openid_connect_update_30006() (openid_connect.install 428-479): for a windows_aad client with no prompt it writes settings.prompt: [], i.e. "send no prompt", which was the old behaviour. But drush deploy runs updatedb and then config:import, and the import replaces it with the checked-in YAML that has no key. Net effect: the module's own migration is undone on every deploy, with a clean config:status. Nobody noticed on feature1 because a fresh login looks the same with or without the prompt.
Fix: add prompt: { } under settings: (or do a real drush config:export after updatedb and commit what it produces; a genuine export always contains prompt).

2. Same file still carries two keys that no longer exist in windows_aad beta10: enable_single_sign_out (replaced by end_session_endpoint in openid_connect_windows_aad_update_9205()) and front_channel_logout_url (now a display-only form item). They survive only because setConfiguration() merges rather than filters, and they will show up as a diff the first time someone saves the client form. Please drop them while fixing 1.

3. ExpandCollapseElementsTest drops the _QAG Request Help with a Sidebar Contact case with a comment saying the sidebar accordion is intentionally hidden at the desktop viewport. That contradicts the comment it replaces, which said the body copy is the hidden duplicate and the long selector existed to avoid it. Nothing in the PHP / openid_connect / flag upgrades changes accordion behaviour. Either confirm the Mayflower behaviour and cite it, or keep the case (a narrow viewport would do).

Also: the changelog only says "Bumped to PHP 8.4", but the PR carries two major prerelease upgrades (flag 5.1.0-beta2, reference_blocked_users 2.0.0-rc1), openid_connect alpha8 which now owns /user/logout, and a changed unwatch URL in flag emails (links in already-sent emails will 404). Those deserve their own changelog lines for release notes and rollback triage.

Everything else checked out: all seven php84 patches are purely mechanical, dropping access_unpublished_listing_fix.patch is safe (1.7.0 has the null guard upstream), the DP-25897 re-roll wires @request_stack correctly, the akamai MR diff is needed (no tagged release has the fix) and stable (MR merged), getAsLink(..., 'default') is required in flag 5.x with no other callers, the AuthTrait logout override matches openid_connect's own test base, and the base-class swap covers all 34 JS tests.