WordPress / WordPress-Coding-Standards

PHP_CodeSniffer rules (sniffs) to enforce WordPress coding conventions
MIT License
2.54k stars 479 forks source link

What's the correct way to disable certain checks? #579

Closed cowgill closed 8 years ago

cowgill commented 8 years ago

For example, we use a CONSTANT for the text domain (no lectures pls) and it's really annoying to be alerted for every single instance so we'd like to disable it.

Our current method is to comment it out directly in the source but that obviously gets blown away next time we update.

Example Usage

<h3 class="widget-title"><?php _e( 'My Listings', APP_TD ) ?></h3>

screen shot 2016-07-06 at 9 44 35 am

Triggered by check_argument_tokens()

jrfnl commented 8 years ago

The simplest way is to have a phpcs.xml file in the root of your project with something along the lines of the below as content:

<?xml version="1.0"?>
<ruleset name="Plugin Name">
    <description>Plugin Name rules for PHP_CodeSniffer</description>

    <!-- ##### WordPress sniffs #####-->
    <rule ref="WordPress">
        <exclude name="WordPress.WP.I18n.NonSingularStringLiteralDomain" />
    </rule>
</ruleset>

For more information - have a browse through the PHPCS wiki.

danielbachhuber commented 8 years ago

For example, we use a CONSTANT for the text domain (no lectures pls)

Does this actually work? My understanding was that it doesn't...

JDGrimes commented 8 years ago

Does this actually work? My understanding was that it doesn't...

Yes, it works at runtime, it just probably won't be parsed properly by some tools that generate POT files from the source code.

jrfnl commented 8 years ago

I can confirm that that works without any problems whatsoever, it's just PHP after all and PHP only looks at the value, not how it received it.

And no worries about the parsing tools either. Nacin's article which everyone keeps referring to is from a time when the intention seems to have been to check the text domain when using the pot generator from the plugin/theme author admin page. However AFAIK that was never actually implemented, nor has this been implemented in GlotPress last I checked. Oh and POEdit doesn't care either.

IMHO it should actually be best practice to use a constant for this rather than a hard-coded string.

[Edit] I mean of course Mark Jaquith's article :confounded:

cowgill commented 8 years ago

Thanks for all the responses! @jrfnl your solution worked perfectly. 👍

We have several submodules pulled into our themes so using a global constant makes life much easier.

As mentioned above, the constant works fine. The main issue is running things like Grunt tasks which treat the constant as invalid.

We've got an issue open for the Grunt plugin we use to address this but it hasn't gone anywhere.