[Task] Codebase should pass linting checks

[eddr]

Improve coding standards across Action Scheduler. We should pass our own linting tests, and ideally those should intersect with the WPCS checks implemented by the WooCommerce Marketplace.

• This accommodates a scenario where a plugin wishes to be listed in the marketplace, but also functions in a standalone capacity (ie, it cannot depend on the version of Action Scheduler bundled with WooCommerce). See discussion in the comments for more context.
• Irrespective of the above, this should result in improved code hygiene for Action Scheduler and less noise when linting locally.
• This is probably best handled incrementally; I advise against anyone submitting a monolithic fixes-everything style PR.

Additionally, as described in issues like this one, we should aim to get Action Scheduler's code to a point where it meets the expectations of the W.org plugin review team.

---

Original title:

Action Scheduler shows phpcs errors using wpcs : can't submit new extension to WC marketplace

Original description:

Hi and thanks for excellent and useful plugin!

I'm facing issues when trying to submit a new extension to the WC marketplace.
The plugin uses Action Scheduler library and it causes the automatic tests to not pass WC own phpcs checks

Any clue what can be done?

Thanks

[barryhughes]

Internal discussion: p1690905319416299-slack-C3L7CFBRV

[barryhughes]

@eddr since you are creating a WooCommerce extension, you can presumably depend on WooCommerce being present (or can test for it). WooCommerce includes its own copy of Action Scheduler, and it should therefore be possible to use that from your extension (or else you can use WC()->queue() which effectively wraps it).

I acknowledge this comes with some trade-offs (ie, you may not be able to take advantage of the very latest functionality)—but it is probably the most practical path forward at present.

[eddr]

Hi! Thank you very much!

I am aware that the AS included in WC, yes
The biggest problem for me is that the extension in mind should work even if WC if not active..

[barryhughes]

Gotcha ... in that case, I don't have an easy workaround I can share. I've updated the issue title and description, though, to create a task for cleaning things up within the Action Scheduler codebase (on our end, it is not likely something we can prioritize straight away, however).

[eddr]

Thanks

I really think it's mostly a problem with the WC extension submitting system

[remcotolsma]

The "Plugin Check (PCP)" plugin detects the following issue in the "Plugin Repo" category:

FILE: packages/woocommerce/action-scheduler/lib/cron-expression/CronExpression.php

Line	Column	Type	Code	Message
234	28	ERROR	WordPress.DateTime.RestrictedFunctions.date_date	date() is affected by runtime timezone changes which can cause date/time to be incorrectly displayed. Use gmdate() instead.

action-scheduler/lib/cron-expression/CronExpression.php

Line 234 in 652735c

$currentDate = date('Y-m-d H:i');

This is a problem, especially with the latest plugin check developments:

Secondly, as of today, when you submit a new plugin to the Plugins Directory, it will first be run through Plugin Check’s Plugin Repo category. If the new plugin has an error level item in this category, the submission will be blocked from being submitted for review, until it is fixed.

https://make.wordpress.org/plugins/2024/10/01/plugin-check-and-2fa-now-mandatory-for-new-plugin-submissions/

Can this be addressed within this issue or should I create a new issue and open a PR?

[barryhughes]

Though that is (or was originally) a vendor library, it's one where we've already made other changes—so I think updating it again should be fine.

Can this be addressed within this issue or should I create a new issue and open a PR?

I think it would be fine to create a PR and link back to this issue ... but, please don't write Closes #971 in the PR description as we need some other work, and have some other PRs under review, that need to be wrapped first (thank you!).

[crstauf]

@barryhughes I've created dozens of PRs of manageable size: one PR per file. That should help you make forward progress on this issue without delay.

There are still a few more files to go, and once those are done, I'll swing back around and investigate the PRs that had checks failures.

[crstauf]

Phew, all PRs have been submitted 😓 , and attention brought to the check failures caused by Composer issue.

Hopefully these small PRs can be accepted quickly. 🤞

[crstauf]

@barryhughes FYI after all PRs have been merged, I plan to run PHPCS across the entire codebase again, as well as organize some things a bit.

[crstauf]

@barryhughes #1214 is my final PHPCS PR. 🎉

[barryhughes]

Thanks so much, @crstauf. We should be in a much better spot now. Taking a moment to itemize some further (hopefully final) to-do items before we can close this:

• lib/cron-expression needs attention, as noted above. Though it is a vendor library, it is one we've adopted and modified directly, so we should consider changes here.
• We have lots of PHPCompatibility.FunctionDeclarations.NewNullableTypes.typeDeclarationFound violations (following the merge of Make nullable parameters explicitly nullable #1205). An easy short-term fix is to exclude this rule, but possibly we should update the woo-sniffs ruleset.
• Some short array syntax uses still to fix.

[crstauf]

Hmm, not sure how I missed the short array syntax fixes. That was the intent of my cleanup branch. 😡

[barryhughes]

Given the number of fixes, I think something was going to be missed 🙃