Opened 13 years ago
Closed 12 years ago
#21507 closed task (blessed) (fixed)
Hide charset setting for new installs
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Charset | Keywords: | has-patch |
Focuses: | Cc: |
Description
If your site is set to UTF-8, we should hide the blog_charset setting field. There is no reason to change it away from UTF-8, and doing so can break your content and possibly make your site insecure.
This won't prevent it from changing via options.php — just hiding the primary UI.
We need to keep in mind that "UTF-8" comes in a few forms, both with and without hyphens (also, case insensitivity). We will need to check those.
Technically, this means we've removed an option from WordPress, so I reserve the right to add back one. :-)
Attachments (3)
Change History (9)
#2
@
13 years ago
- Keywords has-patch added
- Resolution fixed deleted
- Status changed from closed to reopened
[21467] introduced a bug: if you go to Reading Settings and click Save Changes, the charset gets overwritten with an empty string in wp-admin/options.php
(since it's still in $whitelist_options
):
http://core.trac.wordpress.org/browser/tags/3.4.1/wp-admin/options.php#L137
As far as I can see, there's no way to output arbitrary hidden fields using the Settings API.
21507.patch moves the check to the beginning of the form and adds hidden blog_charset
field right after settings_fields()
if the charset is UTF-8.
#5
@
12 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I think I'd rather avoid the hidden input with 21507.diff.
This also protects the option from being changed in multisite (as well it should be), forcing any single-site changes to go through options.php.
In [21467]: