Limit the scope of customPropertiesWhitelist

Open
#1,623 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
php
Domain
tooling

Research direction

Start with the WordPress.NamingConventions.ValidVariableName sniff and its customPropertiesWhitelist configuration. Work through the proposed key="DOMDocument" scope and the DOMXPath and $wpdb examples, then establish how unresolved or arbitrary object return types should behave. Done means the scope rules and their handling are agreed and the whitelist no longer applies to unrelated classes.

Written by the indexing model from the issue text.

Description

Component: Core Type: Enhancement

Problem

The customPropertiesWhitelist property of the WordPress.NamingConventions.ValidVariableName sniff is useful for whitelisting variables that can't be changed, but it risks whitelisting some variables incorrectly, as there's no way to limit the scope of when the whitelist should be applied.

For example, when adding <element value="preserveWhiteSpace"/> to the property, it'd be useful to only apply that to DOMDocument variables.

This should pass:

$doc                     = new DOMDocument();
$doc->preserveWhiteSpace = false;

This shouldn't:

$doc                     = new SomeOtherClass();
$doc->preserveWhiteSpace = false;

Possible Solution

As @jrfnl suggested over on WP45934, we could add a key property to the <element>, allowing a scope to be applied to the whitelist.

<element key="DOMDocument" value="preserveWhiteSpace"/>

This becomes a little trickier with functions that can return an object:

$doc   = new DOMDocument();
$xpath = new DOMXPath( $doc );
$rules = $xpath->query( '/configuration/system.webServer/rewrite/rules/rule[starts-with(@name,\'wordpress\')] | /configuration/system.webServer/rewrite/rules/rule[starts-with(@name,\'WordPress\')]' );
if ( $rules->length > 0 ) {
	$child  = $rules->item( 0 );
	// Can we detect that $child is a DOMNode?
	$parent = $child->parentNode;
}

Or even worse with functions that can return an arbitrary object:

$index = $wpdb->get_row( "SHOW INDEXES FROM $wpdb->signups" );
if ( 'domain_path' == $index->Key_name ) {
	return;
}
Dominant language
PHP
Stars
2.8k
Forks
521
Avg merge
5d 20h
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WordPress/WordPress-Coding-Standards

All issues in WordPress/WordPress-Coding-Standards

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.