Skip to:
Content

BuddyPress.org

Opened 8 weeks ago

Last modified 7 weeks ago

#8339 new defect (bug)

Codebase language improvements for a better contributors inclusivity

Reported by: imath Owned by:
Milestone: 7.0.0 Priority: normal
Severity: normal Version:
Component: Core Keywords: dev-feedback
Cc:

Description

In WP 5.5, contributors have started to avoid using sensible terms (eg: "black", "white") into the WordPress Codebase: https://make.wordpress.org/core/2020/07/23/codebase-language-improvements-in-5-5/

I believe we should do the same starting with these two terms.

Attachments (2)

8339-xprofile.diff (8.9 KB) - added by boonebgorges 7 weeks ago.
8339-activity.diff (6.2 KB) - added by boonebgorges 7 weeks ago.

Download all attachments as: .zip

Change History (10)

#1 @boonebgorges
7 weeks ago

In 12694:

Remove terms blacklist and whitelist in inline comments and local variables.

The change is in order to promote clearer and more inclusive language.

See #8339.

#2 @boonebgorges
7 weeks ago

  • Keywords dev-feedback added; needs-patch removed

In [12694] I made the easy changes.

The remaining instances are a bit more complicated, so I was hoping for review or feedback before moving forward.

BP_XProfile_Field_Type

See 8339-xprofile.diff.

This class has a method set_whitelist_values(), a filter 'bp_xprofile_field_type_set_whitelist_values' and a property validation_whitelist.

  1. I've changed the method to set_allowed_values(), and changed set_whitelist_values() to a wrapper that calls _deprecated_function().
  2. I wrapped the old filter in apply_filters_deprecated() and added a new, appropriately-named filter.
  3. The property is the tricky bit. I renamed it to validation_allowed_values. This could break compatibility if a BP_XProfile_Field_Type extending class references the protected validation_whitelist property. I thought about a magic __get() but this will cause visibility issues, since the property should be protected and __get() will make it public. Our own core field types do *not* directly reference validation_whitelist - we only use the wrapper methods - so I think it's very unlikely that any plugins do so either, which means that this is probably an acceptable break.

Activity and core keyword moderation

See 8339-activity.diff.

The language in WP is 'disallowed keys', so that's what I've used throughout.

A few function names contained blacklist. I deprecated them in 7.0.php. As above, I also deprecated filters, and added new ones with more appropriate names.

[12694] already contains the necessary changes to accommodate the new disallowed_keys option in WP. See https://buddypress.trac.wordpress.org/changeset/12694/trunk/src/bp-core/bp-core-moderation.php

This ticket was mentioned in Slack in #buddypress by boone. View the logs.


7 weeks ago

#4 @imath
7 weeks ago

In 12696:

i18n: add missing /* translators */ inline comments.

See #8339

#5 @imath
7 weeks ago

@boonebgorges I just had a look to 8339-xprofile.diff & 8339-activity.diff. They looks good to me. About the last one, FYI the 7.0.php file is missing into the patch ;)

#6 @boonebgorges
7 weeks ago

Thanks, @imath !

Re 8339-activity.diff - I first generated it without the 7.0.php file, realized my error, then regenerated the diff, but forgot to upload it again :-/

#7 @boonebgorges
7 weeks ago

In 12697:

Remove 'whitelist' language from xProfile component.

This is part of a set of changes to make our codebase clearer and
more inclusive to all contributors.

See #8339.

#8 @boonebgorges
7 weeks ago

In 12698:

Remove 'whitelist' and 'blacklist' language from moderation checks.

This is part of a series of changes meant to promote clarity and
inclusiveness in the language used in our codebase.

See #8339.

Note: See TracTickets for help on using tickets.