#54728 closed task (blessed) (fixed)
Coding Standards fixes for WP 6.0
Reported by: | hellofromTonya | Owned by: | |
---|---|---|---|
Milestone: | 6.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | has-patch |
Focuses: | coding-standards | Cc: |
Attachments (6)
Change History (68)
This ticket was mentioned in Slack in #core-coding-standards by costdev. View the logs.
3 years ago
This ticket was mentioned in PR #2198 on WordPress/wordpress-develop by leskam.
3 years ago
#11
- Keywords has-patch added
Coding Standards fixes for WP 6.0
Trac ticket: https://core.trac.wordpress.org/ticket/54728
SergeyBiryukov commented on PR #2198:
3 years ago
#13
Thanks for the PR! Merged in https://core.trac.wordpress.org/changeset/52684.
@
3 years ago
src/wp-admin/includes/misc.php WordPress.NamingConventions.ValidVariableName and WordPress.PHP.StrictComparisons.LooseComparison
@
3 years ago
Fix (WordPress.PHP.StrictComparisons.LooseComparison) ; and fix typo RE: https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#language
#18
follow-up:
↓ 19
@
3 years ago
Hello @SergeyBiryukov find a lot of "Use placeholders and $wpdb->prepare(); found array_keys (WordPress.DB.PreparedSQL.NotPrepared)" should i fix them?
#19
in reply to:
↑ 18
@
3 years ago
Replying to azouamauriac:
find a lot of "Use placeholders and $wpdb->prepare(); found array_keys (WordPress.DB.PreparedSQL.NotPrepared)" should i fix them?
Yes, please!
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
3 years ago
Hello @SergeyBiryukov thanks for your great job. I have one concern, I thought that as "web server" is two words; RE: https://www.dictionary.com/browse/web-server, https://en.wikipedia.org/wiki/Web_server; we should use it like this "$system_web_server_node"
to respect coding standard https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions. But I saw you put it in one word in the commit, is there a raison for that? please enlighten me.
Replying to SergeyBiryukov:
In 52721:
#23
in reply to:
↑ 22
@
3 years ago
Replying to azouamauriac:
I have one concern, I thought that as "web server" is two words; RE: https://www.dictionary.com/browse/web-server, https://en.wikipedia.org/wiki/Web_server; we should use it like this "$system_web_server_node"
Thanks for the note! It just seemed a bit too long for a variable name :) It refers to the system.webServer
XML node, where webServer
reads as a single word to me. On second thought, I guess you're right and that camelCase should be replaced with two words. I have no objections to changing it.
@
3 years ago
Fix "WordPress.NamingConventions.ValidVariableName.VariableNotSnakeCase" in src/wp-includes/class-wp-http-curl.php src/wp-includes/class-wp-http-streams.php src/wp-includes/category-template.php;
This ticket was mentioned in PR #2429 on WordPress/wordpress-develop by kebbet.
3 years ago
#27
Trac ticket:
https://core.trac.wordpress.org/ticket/54728
SergeyBiryukov commented on PR #2429:
3 years ago
#29
Thanks for the PR! Merged in https://core.trac.wordpress.org/changeset/52957.
This ticket was mentioned in PR #2434 on WordPress/wordpress-develop by kebbet.
3 years ago
#30
Trac ticket:
SergeyBiryukov commented on PR #2434:
3 years ago
#32
SergeyBiryukov commented on PR #2434:
3 years ago
#42
Thanks! Merged in https://core.trac.wordpress.org/changeset/52967.
This ticket was mentioned in PR #2435 on WordPress/wordpress-develop by kebbet.
3 years ago
#43
Trac ticket:
A new set of imporovements. :)
https://core.trac.wordpress.org/ticket/54728
#47
follow-up:
↓ 48
@
3 years ago
@SergeyBiryukov I'm not a fan of some of the recent changes.
Splitting long queries into separate parts and joining them using implode()
makes the code less readable.
If you want to improve those, you can either use multi-line strings or use sprintf()
, which both make for more readable code.
Example:
<?php // Original code: $old_request = "SELECT $found_rows $distinct $fields FROM {$wpdb->posts} $join WHERE 1=1 $where $groupby $orderby $limits"; // More readable than implode: $old_request = " SELECT $found_rows $distinct $fields FROM {$wpdb->posts} $join WHERE 1=1 $where $groupby $orderby $limits"; // Alternative: $old_request = "sprintf( 'SELECT %s %s %s FROM %s %s WHERE 1=1 %s %s %s %s', $found_rows, $distinct, $fields, $wpdb->posts, $join, $where, $groupby, $orderby, $limits );
As for the changes from array()
to compact()
: this is a BC-break which should be reverted.
You are changing the array which is passed to the filters from a numerically indexed array to an associative array and any code which is hooked into those filters which was approaching the array using numeric indexes will now be broken.
#48
in reply to:
↑ 47
@
3 years ago
Replying to jrf:
As for the changes from
array()
tocompact()
: this is a BC-break which should be reverted.
You are changing the array which is passed to the filters from a numerically indexed array to an associative array and any code which is hooked into those filters which was approaching the array using numeric indexes will now be broken.
Thanks for reviewing the changes and noting this!
I will address the first suggestion shortly.
For second one, however, unless I'm missing something, [52974] did not replace array()
with compact()
, but only relocated the compact()
call while removing the redundant array()
at the same time. All of these arrays were associative before the change, not numerically indexed.
As far as I can tell, there is no functional difference between this:
$array = compact( array( 'a', 'b' ) );
and this:
$array = compact( 'a', 'b' );
https://3v4l.org/5WRUs seems to confirm that.
#49
@
3 years ago
For second one, however, unless I'm missing something, [52974] did not replace array() with compact(), but only relocated the compact() call while removing the redundant array() at the same time. All of these arrays were associative before the change, not numerically indexed.
@SergeyBiryukov Ah! I completely overlooked that those filters had a compact()
within the filter call. My bad! (though still good to verify this was the case for all of them)
#51
follow-up:
↓ 52
@
3 years ago
<?php 1 === $_GET['test']
will never evaluate to true, as $_REQUEST
values are all strings. Keep the loose comparison.
#52
in reply to:
↑ 51
@
3 years ago
Replying to knutsp:
<?php 1 === $_GET['test']will never evaluate to true, as
$_REQUEST
values are all strings. Keep the loose comparison.
Or do a strict comparison, but compare against the right type, i.e. '1' === $_GET['test']
;-)
#61
@
3 years ago
- Resolution set to fixed
- Status changed from new to closed
With 6.0 RC1 tomorrow and since coding standards updates usually touch code, I'm going to close this out.
If there are any more changes required between now and the final 6.0 release, this can be referenced and reopened if necessary with dev-reviewed
.
#55647 is open for continuation during the 6.1 cycle.
@SergeyBiryukov commented on PR #2435:
4 months ago
#62
Thanks for the PR! Merged in r58888.
In 52534: