Words have power – removing exclusionary language from code

Originally posted on the Matador Jobs blog, August 18, 2020

Words Have Power

Thanks to the incredible conversations the United States and World are having right now about race and inclusion, it has come to our attention, as software developers, that some of the phrases we use are based on historically racist or classist terms and that our continued use of these terms is insensitive, unwelcoming, and exclusionary.

While insignificant in the giant list of things that need to be changed to bring about true equality and inclusiveness, we at Matador Jobs nevertheless feel we can begin to impact change by stopping our perpetuation of these negative language constructs in our software.

Our changes to exclusionary terms

Based on useful and interesting discussions with other developers around exclusionary language, we found that the items below are the biggest targets for adjustment. In many cases, these changes that can be made are actually more descriptive! Here are the key adjustments we are making in our upcoming releases:

  • Changing whitelist/blacklist to “allow list”/”deny list” to explain lists of explicitly allowed or disallowed items
  • Replacing master and master/slave to main and primary/secondary to explain relationships where one is an authority or primary source to a backup or secondary source.
  • Removing the use of “grandfather”/”grandfathered” to describe backwards compatibility or rights or access given automatically to a legacy user of a feature.
  • Instead of “whitespace” use “empty space”, “blank space”, or a more descriptive term to describe areas that are purposely empty, blank, or clear for readability or design, ie: a “line break” could describe space purposely used to improve readability of code or text.

In the case removing of “whitelist,” we needed to engage our partners at Bullhorn, as one of our uses of the term is derived directly from their official API implementation documentation. After very positive discussions with Bullhorn Support, they are prepared to initially fully support our removal of the term from our documentation and code and are exploring how they too can strike it from their own documentation and code.

Most of these changes will be behind-the-scenes and specific to advanced integration a developer may do with Matador. But, since “whitelist” was a key part of the Bullhorn Connection Assistant, the following change will affect all users. The changes are:

  • “Whitelist” or “Whitelisted” (used as a verb) will become “Register” or “Registered”
  • “[API Redirect] Whitelist” (used as a noun) will become “Allowed API Redirect List”

Our next hotfix release, 3.6.2, of Matador Jobs, will include these changes, with further changes behind-the-scenes in following releases.

Resources

Resources we found helpful in considering these issues include:

https://thenewstack.io/words-matter-finally-tech-looks-at-removing-exclusionary-language/

https://www.duncannisbet.co.uk/removing-harmful-language-from-my-lexicon

How can I know I am writing secure WordPress code?

Security

Even as experienced coder, it can be daunting to try to write secure WordPress code.

There is one golden rule: trust no-one!

But if you habitually make use of a few good tools, you should be able significantly to reduce potential vulnerabilities. As a bonus, secure code tends to be both performant and readable.

Where to begin – good tools

Use the tools that exist – don’t just write your code in a basic text editor!

I would recommend as a starting point using an IDE – Visual Studio Code, PHP Storm (IntelliJ), or, if you want a more editor based option, Sublime Text. Amongst other features, all of these offer code completion and syntax highlighting. This easily eliminates some of the ‘basics’, allowing you to focus on the actual code.

Next, you need a static code analysis tool. For WordPress coders this means installing  PHP_CodeSniffer (https://github.com/squizlabs/PHP_CodeSniffer ). If you integrate this with your IDE, you will get real-time feedback as to whether you are meeting the coding standards that you have selected.  For example, CodeSniffer will complain if you do not sanitize the input, escape the output or use a nonce when receiving data.

Note: A team of volunteers has created a set of WordPress Coding Standards rules (sniffs) to enforce WordPress coding conventions.  You can download these, together with integration instructions, from GitHub (https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards )

Applying the golden rule

What does it mean to ‘trust no-one’?

Your code needs to check that any input passed to it from a user, another coder or function is what you expect and that any time you return content your code confirms that it is the right type of content.

Example of checking input data

In the code fragment below, I first check that a form submitted was created by the website by using a nonce and then use absint() to make sure the form value is a number, followed by using the sanitize_text_field() to clean the name value input.

// Check we have a form field called wp_nonce
// Check the value of wp_nonce is what WP created
if ( isset( $_POST['wp_nonce'] ) && wp_verify_nonce( $_POST['wp_nonce'], 'save_form' ) ) {

 // make sure that a and ID is an int    
 $post_id = absint( $_POST['id'] );

  // - Checks for invalid UTF-8,
 // Converts single `<` characters to entities
 // Strips all tags
 // Removes line breaks, tabs, and extra whitespace
 // Strips octets
 $name = sanitize_text_field( $_POST['name'] );

 // Save form
 }

Examples of escaping output data

It is important to escape any translated content as you don’t know what is in the translation. In the following code fragment, the last thing I do before echoing the html is to pass it through esc_html() to make sure it is valid and allowed html.

 echo esc_html( sprintf( '<p>%s</p>', __( ' Some content to by translated', 'text_domain' ) ) );

You should never trust the output of a function, even if you wrote it, as someone else might change it later. In this example, I use esc_url() and esc_attr() to clean the returned output of the functions.

echo sprintf( '<a href="%s" title="%s">click here</a>', esc_url( get_a_url_from_somewhere() ), esc_attr( get_a_title_from_somewhere() ) );

Writing secure WordPress code – the last word

Security is always going to be a challenge – change is a constant and vulnerabilities exist everywhere. But it is our responsibility as coders to do the best we can. At the very least, consistently using the tools available, applying coding standards and following basic good practice guidelines, is just good sense. It should eliminate a significant proportion of risks and leave you some headspace to tackle the edge-case scenarios.