Implement readme parser check in trunk

[felixarntz]

The legacy-plugin branch has checks that rely on afragen/wordpress-plugin-readme-parser to actually parse the plugin readme, a feature that is currently missing from the trunk branch for the new plugin version.

We should refactor (and by that enhance) our Plugin_Readme_Check to rely on the WordPressdotorg\Plugin_Directory\Readme\Parser class:

• We can instantiate the class simply for the first file in the $readme array, since that array will only have 0 or 1 entries anyway.
• Then we can update the three private methods to accept the instance of the Parser and the single file path, and refactor the logic to use the class instead of manually parsing the file contents.
• Additionally, we can include a new private method check_for_warnings, to ensure we catch other warnings the parser has encountered. While doing that, let's already implement the code from Create a way to remove certain readme warnings, contributors_ignored. #276 in that new method, to address that problem.

[swissspidy]

Related:

• Expand readme check #198

That command also uses the Parser class and reports everything reported by the parser.

[felixarntz]

Thanks for flagging @swissspidy! I think we could potentially combine the two issues, but maybe yours also would encompass things that go beyond this issue (as this issue is focused only on achieving parity with the legacy-plugin branch).

I looked at your related WP-CLI command and have two questions:

• Do you know how the parser classes you reference in https://github.com/swissspidy/validate-readme-command/blob/main/src/Parser.php#L11 related to the afragen/wordpress-plugin-readme-parser? Or is the latter just the latest iteration? I'm wondering since the legacy-plugin branch uses the latter.
• It seems a good chunk of https://github.com/swissspidy/validate-readme-command/blob/main/src/Validator.php is about providing useful user-facing messages for various warnings. Does that mean the warnings the parser itself creates are just "error codes"? If so, I would agree this is a great idea and we could probably incorporate the messages you've been using into an eventual PR for this issue here as well.

[swissspidy]

• Do you know how the parser classes you reference in swissspidy/validate-readme-command@main/src/Parser.php#L11 related to the afragen/wordpress-plugin-readme-parser? Or is the latter just the latest iteration? I'm wondering since the legacy-plugin branch uses the latter.

Both use a copy of the parser class from Meta SVN, so it's the same thing. I think my copy is now just a little outdated as I haven't touched that code in a while. For example it's missing the sanitize_contributors() method (which does not work outside of dotorg anyway).

• It seems a good chunk of swissspidy/validate-readme-command@main/src/Validator.php is about providing useful user-facing messages for various warnings. Does that mean the warnings the parser itself creates are just "error codes"?

That is correct, yes.

[mukeshpanchal27]

Quick question: Which parser do we needs to use? legacy-plugin or @swissspidy's validate-readme-command?

[swissspidy]

For the parser itself, we can use afragen/wordpress-plugin-readme-parser which is more up to date. Both are the same, but this one is simply more up to date.

For reporting errors based on the parser results, we can look at validate-readme-command for inspiration for sure.

[afragen]

FWIW it's my intention to keep the readme-parser updated. I've made it simple to do this. I only need to be aware of when updates occur or run command in the repository at regular intervals.

[afragen]

If interested you can take a look at the class I use to interact with the readme-parser here, https://github.com/afragen/git-updater/blob/develop/src/Git_Updater/Readme_Parser.php

[ernilambar]

I am working on this.