Opened 6 months ago
Last modified 3 weeks ago
#64581 new feature request
Allow serialized options read-only view
| Reported by: | anatolinicolae | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Options, Meta APIs | Version: | 2.0.2 |
| Severity: | trivial | Keywords: | has-patch has-screenshots |
| Cc: | Focuses: | ui, administration |
Description
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.
Attachments (1)
Change History (10)
This ticket was mentioned in PR #10853 on WordPress/wordpress-develop by @Presskopp.
6 months ago
#1
- Keywords has-patch added
#2
@
6 months ago
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.
This ticket was mentioned in PR #11646 on WordPress/wordpress-develop by @anatolinicolae.
3 months ago
#3
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. readonlytextarea +nameattribute 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_valueout of per-branch assignments, collapses thedisabled-class logic into a ternary, merges thehome/siteurlWP_HOME/WP_SITEURLchecks.site-settings.php: hoists the\$ltr_fieldslist 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 throughesc_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 datatoggle; expanding it shows the rawa: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/siteurlrows whenWP_HOME/WP_SITEURLconstants are defined — they remain disabled inputs.
#6
@
2 months ago
Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.
#8
@
8 weeks ago
@desrosj PR https://github.com/WordPress/wordpress-develop/pull/11646 maintains the expected behavior of #2591, read-only fields not allowing edits on submit.
#9
@
3 weeks ago
- Keywords needs-testing removed
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.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Fixes https://core.trac.wordpress.org/ticket/64581
This replaces the hard-coded "SERIALIZED DATA" placeholder in
wp-admin/options.phpwith a read-only display of the actualunserialized option value.