Allow serialized options read-only view

[anatolinicolae]

The options.php page currently overwrites an option value when it is serialized with 'SERIALIZED DATA'.

However, these values will most likely never be changed manually as it would require users to deserialize, edit and serialize it back via some manually crafted script, while it still does make sense to display the proper value regardless for i.e. debugging purposes without looking up keys in the DB.

Patch could be as simple as returning $value = $option->option_value; in options.php assuming there's no further concerns with this page scope. Keeping $disabled = true; would prevent manual editing, while having no impact on eventual save.

Permissions would still apply and this page would only remain visible to admins (not even linked anywhere AFAIK). There are no further security concerns about the option value, as non-serialized options already expose their values.

Fixes https://core.trac.wordpress.org/ticket/64581

This replaces the hard-coded "SERIALIZED DATA" placeholder in
wp-admin/options.php with a read-only display of the actual
unserialized option value.

[Presskopp]

When taking this change into account, we should be aware that the same code is present in network/site-settings.php. Note: Because it's a debug page, no i18n is taking place.

Fixes https://core.trac.wordpress.org/ticket/64581

## Summary
Replaces the hard-coded SERIALIZED DATA placeholder in wp-admin/options.php and wp-admin/network/site-settings.php with the raw serialized value rendered read-only inside a native <details>/<summary> element. The value remains non-editable and is excluded from form submission, so it cannot be accidentally corrupted on save.

This is an alternative implementation to #10853 based on the ​feedback left there:

• No JavaScript. Uses the native <details> disclosure widget instead of a custom JS toggle.
• Raw serialized value, not print_r(). Preserves the exact stored value so it can be safely copied / inspected without lossy reformatting.
• readonly textarea + name attribute omitted so the value cannot round-trip back into the database via the form.
• Translatable string __( 'Serialized data' ) replaces the hard-coded English placeholder.

The same pattern is applied to the network site settings screen, which had the identical placeholder issue.

## Incidental cleanup in the touched code

• options.php: hoists $value = $option->option_value out of per-branch assignments, collapses the disabled-class logic into a ternary, merges the home/siteurl WP_HOME/WP_SITEURL checks.
• site-settings.php: hoists the \$ltr_fields list out of the per-row loop, consolidates four duplicated <tr> blocks into a single row with inline branches, and removes a double-escape on serialized-string values — esc_html() was applied at assignment and then again at output through esc_textarea/esc_attr, corrupting any unserialized string containing <, >, or &.

## Test plan

• [ ] On Single Site, visit /wp-admin/options.php. Any option whose value is a serialized array/object now renders as a ▸ Serialized data toggle; expanding it shows the raw a:N:{…} payload in a disabled textarea.
• [ ] Submit the form and confirm the serialized option's value is unchanged in the DB (it must not be present in $_POST).
• [ ] Serialized-string options (e.g. some legacy single-string serialized values) still render as their unserialized text in a normal input/textarea, and special characters (<, >, &) display correctly without double-escaping.
• [ ] On Multisite, edit a site via Network → Sites → Settings and verify the same behaviour for serialized values there.
• [ ] Visual regression on home/siteurl rows when WP_HOME/WP_SITEURL constants are defined — they remain disabled inputs.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Introduced in [4382]. See #2591.

[anatolinicolae]

@desrosj PR ​https://github.com/WordPress/wordpress-develop/pull/11646 maintains the expected behavior of #2591, read-only fields not allowing edits on submit.

[sanayasir]

Hi there,

I tested this on my local WordPress development setup.

Before applying the patch, serialized option values on wp-admin/options.php were displayed as SERIALIZED DATA, making it impossible to inspect the actual stored value.

After applying the patch, the actual serialized value is displayed instead of the SERIALIZED DATA placeholder, while the field remains disabled/read-only. Non-serialized options continue to display normally.

The patch works as described in the ticket and improves the debugging experience without allowing serialized values to be edited.