[wp-trac] [WordPress Trac] #50413: Enhancement: Update code and comments to use more inclusive language.
WordPress Trac
noreply at wordpress.org
Wed Jun 17 18:07:37 UTC 2020
#50413: Enhancement: Update code and comments to use more inclusive language.
-----------------------------+-----------------------------
Reporter: strangerstudios | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: trunk
Severity: normal | Keywords:
Focuses: |
-----------------------------+-----------------------------
Specifically, we want to change any use of "blacklist" to "blocklist" and
any use of "whitelist" to "safelist".
In some cases a different word may be more appropriate or the language can
be changed to avoid the issue.
I spent some time finding all of the cases of blacklist and whitelist in
the core WP code and took notes on what actions could be taken.
Sometimes we can just change the words with no downside (that I could
see). Sometimes the word use is based on a dependency in an included
library. Sometimes the use is in a default theme. Sometimes we need to do
more work to deprecate old function and filter names.
Here are my all my notes. I still need to do more research on uses of
whitelist in particular.
I think we should break things down into smaller chunks. The "easy" cases
can be separated out. And some of the cases are related around a common WP
feature.
- START NOTES -
Older trac ticket that updated the language on the front end.
https://core.trac.wordpress.org/ticket/48900
Here are the instances where the term blacklist shows up in the code.
https://github.com/WordPress/wordpress-
develop/search?q=blacklist&unscoped_q=blacklist
A) The password-strengh-meter.js file uses blacklist
https://github.com/WordPress/WordPress/blob/2a0489ec49c449894471a599c1811aaf0fcbbb22
/wp-admin/js/password-strength-meter.js
The blocklist functionality is only in our WP code. The zxcvbn library
doesn't have a blocklist.
1. Change the method and variable names in this file.
2. This other WP core file uses the old method name:
https://github.com/WordPress/WordPress/blob/001ffe81fbec4438a9f594f330e18103d21fbcd7
/wp-admin/js/user-profile.js#L223
3. We need to check if other plugins are using the specific
userInputBlacklist method. At least one use here:
https://github.com/strangerstudios/paid-memberships-
pro/blob/272b47cf1cf041a45734678dfbf15b3ca699a241/js/pmpro-login.js#L15
4. We potentially need to keep a version of the old method that is
deprecated.
5. Change the use in this unit test: https://github.com/WordPress
/wordpress-
develop/blob/98584d6e1191ad7ed62f79c13c343dade456d95d/tests/qunit/wp-
admin/js/password-strength-meter.js
---
B) The sodium_compat library uses the term in its code.
https://github.com/WordPress/WordPress/blob/d4ef90b236ce340591bd284b2ecaa085e4f42ffd
/wp-includes/sodium_compat/src/Core/Ed25519.php#L380
1. We should ask the maintainers of that library to consider changing
their code to use the more inclusive terms. I believe this is the repo
https://github.com/paragonie/sodium_compat. I didn't find any existing
issues or PRs that address this. We could create an issue and/or PR for
them.
---
C) The twentynineteen npm package.json has a config options for
rtlccssConfig called blacklist. The blacklist value is set to {}. Based on
this doc (https://rtlcss.com/learn/usage-guide/options/index.html) the
default is {} and unlikely to change IMO. There is another option
"useCalc" that isn't set in our package.json.
1. We can remove this line
https://github.com/WordPress/WordPress/blob/9e9be350e2b64d5c680219608b346e606f2223dc
/wp-content/themes/twentynineteen/package.json#L23 and nothing should
break.
---
D) The twentytwenty npm package.json has the same line as above.
1. We can remove this line
https://github.com/WordPress/WordPress/blob/9e9be350e2b64d5c680219608b346e606f2223dc
/wp-content/themes/twentytwenty/package.json#L36 and nothing should break.
---
E) There is a function called wp_blacklist_check() which checks if a
comment contains blocklisted characters or words.
https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
includes/comment.php#L1277
1. There's also a hook named wp_blacklist_check.
https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
includes/comment.php#L1290
We'd have to change the name, change the docs, and keep a deprecated
version of the hook for some time.
2. We should check if other plugins are calling the function directly and
assuming so, create a deprecated version of the whole function.
https://wpdirectory.net/search/01EADC773CDTAXVXRYYGB37NBT
In comment.php, we would also then have to replace the use of blacklist in
the comment here: https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
includes/comment.php#L17
and when it's used here: https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
includes/comment.php#L818
3. There is one unit test that uses the old function name.
https://github.com/WordPress/wordpress-
develop/blob/6b366c6620fdd5960cedcdf80955966a715efa82/tests/phpunit/tests/comment/wpBlacklistCheck.php#L18
After we make all other changes, we should be able to rewrite this test to
use the new terms.
4. Using blacklist_keys in the HTML attributes (name, id) of the Comment
Blocklist field on the Discussion Options page.
https://github.com/WordPress/wordpress-
develop/blob/8b9823f53621a63d0a47626920f6930f35db160c/src/wp-admin
/options-discussion.php#L209
Change all blacklist_keys to blocklist_keys.
5. When we change the name of the textarea, we will also have to change
the name of the parameter we look for in the server code. That would be
here https://github.com/WordPress/wordpress-
develop/blob/50ece6d31c33b056b91fc1f204c618c76368925b/src/wp-
admin/options.php#L106, and it seems we can just change the name there.
6. This option is also set up as a default here
https://github.com/WordPress/wordpress-
develop/blob/8b9823f53621a63d0a47626920f6930f35db160c/src/wp-
admin/includes/schema.php#L450. Change the name there.
7. The formatting rules for this option are here
https://github.com/WordPress/wordpress-
develop/blob/b58973554da40b4965458d993a4703ec81e7ad28/src/wp-
includes/formatting.php#L4881. Change the name there.
8. On existing sites, the option is stored in the DB as blacklist_keys.
We would want to run a SQL query like this on update.
UPDATE $wpdb->options SET option_name = 'blocklist_keys' WHERE option_name
= 'blacklist_keys';
Were other plugins accessing the option from the DB directly?
---
F) Comment in theme.php https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
includes/theme.php#L2828
We can change Blacklist to Blocklist or reward the comment in general to
avoid it.
---
G) This unit test for attachments uses the terms blacklist and whitelist
in its tests of the mime type filter for uploads.
https://github.com/WordPress/wordpress-
develop/blob/cfc3b57488458801c64c750cb500c98c1ef635ad/tests/phpunit/tests/post/attachments.php#L496
We can change those terms without breaking anything. The mime type filter
itself (https://developer.wordpress.org/reference/hooks/upload_mimes/)
doesn't use block/black/white/safe language anyway. So we can probably
rename things to make the test even clearer.
---
H) This unit test for includes/schema.php has the word blacklist in a
comment.
https://github.com/WordPress/wordpress-
develop/blob/e72fff9ceffb41d22c48febfc5f97c0cd46f5884/tests/phpunit/tests/admin/includesSchema.php#L162
We can change that to blocklist or someone who understands what is being
tested can probably rewrite the comment to be more clear.
---
I) The twentyfourteen theme has the word blacklist in a comment.
https://github.com/WordPress/wordpress-
develop/blob/8b9823f53621a63d0a47626920f6930f35db160c/src/wp-
content/themes/twentyfourteen/inc/featured-content.php#L236
We could say "We need to respect post ids already being excluded." or "We
need to respect post ids already in the array."
---
J) The wp-admin/options.php file has a variable $whitelist_options that is
used to make sure only specific options get updated on the options pages.
https://github.com/WordPress/wordpress-
develop/blob/50ece6d31c33b056b91fc1f204c618c76368925b/src/wp-
admin/options.php
1. Can change all uses of that variable within this file to
$safelist_options.
2. There is a filter whitelist_options as well here
https://github.com/WordPress/wordpress-
develop/blob/50ece6d31c33b056b91fc1f204c618c76368925b/src/wp-
admin/options.php#L209
We can change that to safelist_options. We would need to add a deprecated
filter for the old use.
We would need to update the documentation.
3. Update the error message here https://github.com/WordPress/wordpress-
develop/blob/50ece6d31c33b056b91fc1f204c618c76368925b/src/wp-
admin/options.php#L224
---
Here are some instances where whitelist shows up in the code. Many of
these are related to the above instances of blacklist, many are not. I
haven't code through all of these yet.
https://github.com/WordPress/wordpress-
develop/search?q=whitelist&unscoped_q=whitelist
K) In wp-admin/includes/plugin.php there are a couple of related functions
that have the word whitelist in them. add_option_whitelist() and
remove_option_whitelist().
https://github.com/WordPress/wordpress-
develop/blob/3bdf8b7b020be9b3b2308a4fdf6a27d5dde15dc4/src/wp-
admin/includes/plugin.php#L2139
Also option_update_filter() is a callback for the whitelist_options filter
and calls those functions.
There are 2 global variables $whitelist_options and
$new_whitelist_options.
The $new_whitelist_options global seems to only be used by the
register_setting() function https://github.com/WordPress/wordpress-
develop/blob/8b9823f53621a63d0a47626920f6930f35db160c/src/wp-
includes/option.php#L2117
But it's also showing up in 108 or so plugin:
https://wpdirectory.net/search/01EB1MCARJHZ77593CWHEXWH3C
We could potentially update option_update_filter() function and remove the
need for the $new_whitelist_options global by just using the
$wp_registered_settings one and building a one time array in the right
format for the add_option_whitelist function. The "group" is in the args
for the options in $wp_registered_settings. We would create arrays out of
those groups.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/50413>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list