Adopt WPCS for Themes and Plugin Directory

I would like to get the general sentiment about adopting WPCS to our plugin and theme Directory.

I added a poll to vote on

  • “Enforce” (make it mandatory to pass WPCS 100% unless exceptions which need to be documented in a code comment)
  • “Label” (provide a label or badge to plugins/themes that do follow the standards, but make it optional, thus not mandatory)
  • “Other” (do not agree with either, please explain in comments why and what instead)

Obviously, should go without saying, security related issues will or should always be enforced.

If this poll would show a general acceptance, we can still discuss if certain rules (like Yoda) could be “ignored”.

IMO, it would do a big advantage to our directory if everything would be following the same standards, not only from a quality point of view, but also from a review point of view (if a reviewer needs to dig inside 1000 errors, 998 of which are just beautifier related, it makes it very hard to find actual issues)
Also, it could be a good “teaching resource” for novices, and generally just a “best approach” to enforce standards.

  • Enforce
  • Label
  • Other

0 voters

Users don’t care about labels or code quality, so label would be useless.

Enforcing is probably not the right approach, but I’m all for recommending it in the guidelines.

1 Like

Right now I’ve 13 plugins published in the directory.
Most of them follow a custom ruleset (no yoda, no array long sintax) that is very close to CodePotent’s one (I’ve adopted several of his plugins).

Those 13 plugins are used on 109 sites, 44 are hosted by me.

Guess what I think about fixing “beautifier related” errors :sweat_smile:

1 Like

I am less referring to existing plugins and more about new ones that need to be reviewed.
Of course we wouldn’t go around asking already admitted plugins to please update their non-security code standards (because supposedly those plugins would not have security issues, since admitted…)

See it from this point:
Guess what I think about reviewing a plugin with 780 errors and within them, some 25 about security.
There is no productive way to spot those real issues, other than reading thru 780 errors :slight_smile:

So my main interest comes from that angle, but also from the angle that we do have a bunch of “this is better” code, where really there is a standard, which, well… as any standard is there for exactly that: avoid the differences and make it unison.

but I see there is little understanding in this or agreement, so I guess that will remain a recommendation (which is === to saying “do what you want, we do not care”, because that is what recommendations are, really :slight_smile: )

I find it bad, but… majority rules I guess.

1 Like

Really I can hear a lot of 4 letter words :rofl:

I appreciate a lot what you are doing.

Its more like 3 letters:
w h y

No worries, it was my first.
And my last, if we can’t agree on this, because I am not going to spend my life reading thru “you shall not use spaces instead you shall use tabs” and then oversee a “$_POST accessed without sanitising” (you get the idea).

Quickly going to check if I can suppress the bf notices in WPCS easily without lots of hurdles so for reviews in order to just flag actual security issues…

I’ll let the poll run for a day or two and then close… just for the sake of poll.

1 Like

Maybe you can just look at what phpcbf can’t fix, like this:

15 | ERROR | [ ] Use placeholders and $wpdb->prepare(); found $sql (WordPress.DB.PreparedSQL.NotPrepared)

But how do you look at this, if it is nested inside 700 other errors? That is the issue. Of course I could run the bf when scanning, so those errors go away, but it is not the purpose of a review, to fix issues…

I asked in WP slack and turns out there are some options ( > WP QA) that seem promising and hide a bunch of nonsense from the report while still checking on actual errors.
Playing with it now, as this might be a possible solution for plugin/theme reviewers.

I still think enforcing these standards would make look CP software a tad “elevated” towards standard WP. Also because we have a chance to educate generations to come.

I am not going to make any changes to code because someone doesn’t like the coding standards I use.

1 Like

This works pretty well:
phpcs ........ --tab-width=100 | grep -v '[x]'

Seems interesting.
If a ruleset with security-only sniffs will be required it’s OK for me following it.

Security is already enforced (at least in theory)

This is basically about the whole standards, to make everyones life easier. Not just newcomers but also experienced folks would profit.

I am proceeding tomorrow with the thing there from GIT, it definitely should be possible to be used without most of the “beautifier” (lol) errors.

How does this sound to you:

I am not going to make any changes to translation because someone doesn’t like the words standards I use.

That is what standards are for!
To avoid having to make changes because someone likes A more than B. Standards are something all agree upon, and none of them are retromandatory, and they describe a repeating pattern of how something is approached.

Enforcing WPCS would add another barrier to entry. We could mention that WPCS is recommended and plugins/themes passing WPCS would be approved quicker, to try and incentivize it. If we could automatically run WPCS on submitted plugins/themes, that would be a nice way to check them and push them to the top of the queue if they pass without errors.

We should also have a developer’s guide about setting up and using WPCS. Make it easier for developers to learn it.

It would be nice if there was a way to create web GUI for WPCS, so a developer could upload a zip file on a page and get it proccesed by WPCS. Something similar to how wpseek does function/version check. Just a thought.

1 Like

How would we run things automatically if we do not want to enforce them?
Machines know even less than humans ab about what a real issue is, and what a false alarm

If we don’t want these standards it’s fine. But either we do it or we don’t. Automated tests (which they are basically already but worthless without human interaction) and candies for those who follow the tests does not really solve the issue. Although the candies maybe would indeed motivate some adoption.

Enforcing standards does btw not add Barriers
It removes them

Who knows how to code also knows how to follow a standard (it actually makes it easier because the sniffer tells you what you did wrong)
I’d even go as far as saying that who does not know too well how to code actually can learn with the standards whereas for someone who is since years coding it actually is hard to change mindset and adopt some (new) standard.

Spending time on GUI and such when the real problem is “I don’t like the standards” - not “I don’t know how to use them” - is not worth it.

These tests are already as automatic as they can be. Without human behind it they are mostly useless.
If someone wants to spend time on a gui for it, yeah sure. But what for exactly I have to ask?
We clearly do not want the standards (because considered unworthy of our time or unrequired for quality code or wrong and replaceable by better ones perhaps)
A gui is not going to solve a thing related to that.

Btw just to be clear- maybe one day we’ll had cp meetings in person and it’ll become obvious:
I despise rules!

My entire life is a summary of broken rules lol

Yet I believe in standards when they make life easier
Like airplane tickets, also should get a darn standard
Like grammatical rules. They make it easier to understand each other I guess.

It’s very similar in code.

Take a simple array for example

Everyone who understands English understands at least the intention of array()
[ ] is meaningless compared to that.

I’m not against coding standards. I don’t like WPCS. Too many spaces for my space bar :rofl:

Having a new smart code standard for CP would be as cool as stupid, because it will break backporting.

I get your point, yet I never use spaces. I also know that WPCS is often like “Oh, phpCS does it like that, so lets do it the other way around” (like camelcase, or classnames, etc). Yet, to change that, as you say, it is too late, since we inherit from WP a lot.

Mostly, all I do after coding is press “beautify” and those spaces get added for me, directly in the IDE :wink:
That is the part the machines can do for us.

Then I concentrate on all the warnings it couldn’t fix, until the code says 0 errors.
It helped me a lot to also learn, as well.
Like the spaces… they are often not pointless. If you need to highlight some variable or add arguments, it is easier when there are spaces between it (var) and the parentheses, as example.
Or an array on multiple lines helps to comment out single members, quickly. An if/else on multiple lines instead of one chunk helps setting breakpoints easier.
Or the example of [] versus array().

Anyway, I see it is a lost cause :stuck_out_tongue:

And yet you continually use the wrong words after being told it’s confusing. (were vs. where, thou vs. though, wether vs. whether)
Programmers write whatever works in the moment, and rarely go back to it unless there’s a bug.

It was a close thing, actually, when the JS guys wanted to change the PHP standard for that one to look more like JS. That was one of my arguments against it changing. Also that it is so much easier to read array than []. For those of us with older eyes, [ looks very similar to (.

You should be able to change the ruleset so that the spacing stuff is either a warning or info instead of error.

As for a GUI, yes please. I haven’t been able to install what is needed on my system, not sure why.
There is the PHP Compatibility Checker plugin, which does this already. There is also the Theme Sniffer, which the Theme Review team was working on but changed directions gitHub.
Looking for that link, I found Theme Grep.

The WP plugin team manages to review lots of plugins pretty fast, with no enforced standard. I’ll bet they have some tools. I know Mika has mentioned a set of grep commands she uses.

I’m pretty sure that beda is a non-native English speaker and as such does very well.

There are some elements of wpcs which are decent, but it throws far too much pointless crap up. I’ve started editing the WordPress sniffs to stop it doing some of them (I’ll probably look into making myself a ClassicPress version once I have time so I can have the standard WP and CP ones at the same time).

Code quality as it relates to formatting is subjective. We have a standard for core because it’s good to keep the code inside a single project formatted the same, but there is no reason to require plugin developers to use the same standard.

Yes, as well as some kinds of code quality issues that we can find automatically, like using translation functions in a way that will not work.

One of the first things we need to do is make a custom WPCS ruleset that shows only the issues we actually care about. One way to do this is by editing the phpcs.xml file, I am sure there are others.