CS/QA update for WPCS 1.0.0, PHPCS 3.3.1 & PHPCompatibility#1311
CS/QA update for WPCS 1.0.0, PHPCS 3.3.1 & PHPCompatibility#1311jrfnl wants to merge 4 commits intoAutomattic:masterfrom
Conversation
…heme The `wp_enqueue_style()` function allows for passing a `$version` parameter which is used to force browsers to load a fresh copy of a stylesheet when it has been changed. If this parameter is not passed, the version number will be set to the version of the WP install which doesn't make sense at all for a theme which is not shipped with WP itself. This commit adds a `_S_VERSION` constant which should be changed to the current version number of the actual finished theme on each new release. This constant is subsequently used in all `wp_enqueue_style()` function calls to ensure that on each new release of the theme, the browser cache is cleared for these stylesheets. Ref: https://developer.wordpress.org/reference/functions/wp_enqueue_style/
Since mid July, the PHPCompatibility project offers dedicated CMS rulesets which already account for all back-fills/poly-fills. This commit removes the `_s` native version of that ruleset in favour of using this dedicated WP-based ruleset. Additionally, the PHPCompatibility repo has moved to a dedicated GitHub organisation, so that change is included here as well. Refs: * https://github.com/PHPCompatibility/PHPCompatibility/releases/tag/8.2.0 * https://github.com/phpcompatibility/phpcompatibilitywp Note: I would strongly recommend installing these dependencies via Composer instead. grappler has created a good setup for this in PR 1291 which I would recommend for merging, though it will need to be updated to be in line with the changes made in this PR.
... and sniff against a high PHP version for the fastest and most reliable results. No ruleset changes are needed. Refs: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/releases/tag/1.0.0
|
Hmm... no response at all and in the mean time WPCS 1.1.0 has come out... makes it difficult to keep up. |
|
If I was in charge I'd say go for it! Looks good. |
|
I'm willing to update this PR to account for WPCS 1.1.0 as well as PHPCompatibilityWP 2.0.0, however, I can't really be bothered if this PR is left open to rot.... |
|
This looks good. |
Except the build won't pass anymore now WPCS 1.1.0 has come out... |
|
Then we should update it. 😝 |
|
Just checking in - WPCS 1.2.0 has come out today. If I would update this PR to fix the issues and make the theme comply with WPCS 1.2.0, is there any chance of the PR being merged within a reasonable time-span (max 2 weeks) so it will not go stale again ? |
|
Hi @jrfnl |
|
@limestreet I'm aware - see: #1311 (comment) |
|
I missed that one :) |
| wp_enqueue_style( '_s-style', get_stylesheet_uri(), array(), _S_VERSION ); | ||
|
|
||
| wp_enqueue_script( '_s-navigation', get_template_directory_uri() . '/js/navigation.js', array(), '20151215', true ); | ||
| wp_enqueue_script( '_s-navigation', get_template_directory_uri() . '/js/navigation.js', array(), _S_VERSION, true ); |
There was a problem hiding this comment.
Can we leave the version as is? The script does not get changed with every theme version. This way we would not need the constant.
There was a problem hiding this comment.
Except that the scripts have been changed a couple of times already and people keep forgetting to update this cache-busting number, so I would strongly recommend leaving it as is (with the constant), as refreshing the script once on every new release is a minor slow-down, while serving an out-of-date script can break a site.
There was a problem hiding this comment.
I don't agree but I don't want to stand in the way of this PR being merged. We might need a PR for https://github.com/Automattic/underscores.me/ too to search and replace _S.
|
The build is failing on a missing dependency, the Paragonie compat sniff. It seems like it'd be pretty simple to also install that along the other sniffs, I'd be happy to help if that'd keep this PR moving forward. |
|
@enkrates The build still wouldn't pass, but that is because no-one of the maintainers bothers to merge in a timely manner. |
|
Where are the maintainers of this build?
…On Tue, Mar 19, 2019, 08:33 Juliette ***@***.***> wrote:
@enkrates <https://github.com/enkrates> The build still wouldn't pass,
but that is because no-one of the maintainers bothers to merge in a timely
manner.
See #1311 (comment)
<#1311 (comment)> and #1311
(comment)
<#1311 (comment)>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1311 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ae6ilwxZ1WbjCg8fXIydnUuDr323swv5ks5vYQM7gaJpZM4V1DuI>
.
|
|
@jrfnl If you'd like to update this PR to pass the build and update the version of WPCS I'll get it merged in a timely manner. |
|
@jrfnl I haven't kept up with this much. Are you done with it and just waiting for it to be merged? Trying to get a sense of current status without reading the entire thread. It seems like it was ready a while back and then nothing happened. |
|
@philiparthurmoore TL:DR: This PR needs a big update as it was left to rot for a year and a half and all the standards involved have moved on since then. I'd be willing to do the update, but only if I have a solid commitment that the PR will be reviewed & merged within two weeks of doing the update as otherwise it will quickly be out of date again. Note: By now, I have very little faith in anything being merged within a reasonable timespan in this project based on (the lack of) progress on any PR in the past two years. Also: it would be so much better if this project would use Composer to manage the (dev) dependencies as that way, it won't be bound to From the PR description above:
|
|
@jrfnl, To be honest, I don't see the point of submitting another PR unless there is a firm commitment from the Automattic theme team to revive _s. Otherwise, I consider it in maintenance mode until I see activity that proves otherwise. I have the rights to merge pretty much anything and everything regarding _s but it doesn't make any sense for me to be the one doing the work if Automattic is using _s (or not) for themes now. Dave mentioned that they were using another starter theme a while back so I'm still a little confused about who leads this now. |
|
@jrfnl Begetting a child and being pregnant takes ~50% of time this PR gets merged. 👶 👶 |
|
@szepeviktor I'd still rather send in a PR though ;-) |
Changes proposed in this Pull Request:
This PR updates the CS/QA related toolset to use the latest versions of these tools and updates the code-base to comply.
Commit details:
QA: Break stylesheets out of browser cache on each new release of a theme
WPCS 1.0.0 contains a new sniff which identifies this issue, which is why it has to be solved for the update to be possible
Type: Functional change
The
wp_enqueue_style()function allows for passing a$versionparameter which is used to force browsers to load a fresh copy of a stylesheet when it has been changed.If this parameter is not passed, the version number will be set to the version of the WP install which doesn't make sense at all for a theme which is not shipped with WP itself.
This commit adds a
_S_VERSIONconstant which should be changed to the current version number of the actual finished theme on each new release.This constant is subsequently used in all
wp_enqueue_style()function calls to ensure that on each new release of the theme, the browser cache is cleared for these stylesheets.Ref: https://developer.wordpress.org/reference/functions/wp_enqueue_style/
CS: Minor fixes to comply with WPCS 1.0.0 / PHPCS 3.3.1
Type: CS update
Nothing very interesting, just some minor fixes to comply with the latest versions of all sniffs being tested against.
Use PHPCompatibilityWP
Type: Build tools
Since mid July, the PHPCompatibility project offers dedicated CMS rulesets which already account for all back-fills/poly-fills.
This commit removes the
_snative version of that ruleset in favour of using this dedicated WP-based ruleset.Additionally, the PHPCompatibility repo has moved to a dedicated GitHub organisation, so that change is included here as well.
Refs:
Note: I would strongly recommend installing these dependencies via Composer instead. @grappler has created a good setup for this in PR #1291 which I would recommend for merging, though it will need to be updated to be in line with the changes made in this PR.
Use WPCS 1.0.0 and sniff against a high PHP version for the fastest and most reliable results.
Type: Build tools
No ruleset changes are needed.
Refs: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/releases/tag/1.0.0