Dev Chat Summary: June 13th (4.9.7 week 4)

This post summarizes the dev chat meeting from June 13th (agenda, Slack archive).

4.9.7 planning

Updates from focus leads and component maintainers

  • The PHP team posted summaries from their last two meetings covering progress and decisions on #43986 and #44350 as well as the approach for #43987. Join them next week on Monday, June 18th at 15:00 UTC in #core-php as they continue the discussion on these two tickets.
  • The REST API team would like a core committer’s review on #38323, so if you’ve got some time then please help out there.
  • And a reminder for those heading to WCEU that Contributor Day is tomorrow, Thursday, June 14th. If you’re in town, then please consider attending… thanks!
  • No design lead for Customize focus while @melchoyce is on sabbatical until September 10th

Devchat coordination

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats.
  • If you’re open to collecting agenda items and publishing an agenda, running the actual devchat meeting, and/or publishing a devchat summary then please comment here or ping @jeffpaul if you’re able to help out… thanks!

Next meeting

The next meeting will take place on June 20, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-7, #core, #core-customize, #core-restapi, #dev-chat, #summary

What’s new in Gutenberg? (5th June)

This release marks the 30th update to the editor plugin. The highlights are broken down below.

Block Library

Arguably, one of the key pieces of the new editor UI is the block library or inserter. Unifying the way users can insert content has been one of the main objectives of the whole project. It has gone through multiple iterations and testing; balancing clarity, usability, flexibility, and extensibility. This release offers the result of some very fruitful collaborations between designers and developers.

Notably, tabs are being removed; blocks have bigger surface areas; and plugins can supply a distinct color for the block icon background. This seeks to allow the inserter to better scale while retaining visual clarity. The other addition to the inserter is related to the new concept of child blocks explained below.

Child Blocks

The editor has had support for nesting blocks since around the beginning of this year. With 3.0, a block author can now also register a block as being a child of another block by declaring parent: [ 'block-name' ]. This now causes a few changes in the interface: the root inserter won’t show child blocks unless the user is within the context of the right parent block. (It aims to reduce the amounts of blocks shown at any given time by making the inserter more contextual.)

Note that for a block to be effectively a child two conditions must apply:

  • The block must provide a valid parent property.
  • The parent must have an InnerBlocks area declared.

This is how the block library looks after both changes:

Showing a custom block with custom colors.
A block that contains children.

Theme Styles

During the whole process of Gutenberg, we have come to the realization that in order to have the most flexible system for styling within themes — and letting us get closer to visual parity between front-end and the editor — we had to separate presentational styles from structural styles when it comes to individual blocks. So far, we have not been loading presentational styles on the front-end in order to avoid unintentional changes to site’s appearance, but that also causes issues for new themes that would like to start working from the visual design baseline that Gutenberg offers by default as shown on the admin side.

The decision has been made to allow themes to opt-in to these styles with an add_theme_support( 'wp-block-styles' ) registration. This will allow us to keep (or reintroduce) some more opinionated styles for elements like Quotes, Tables, the Separator, and so on.

3.0 🍠

JS docs initiative: Add inline-docs for JavaScript! (part 2)

Because of a restriction of wordpress.org, you cannot comment on posts older than 120 days. This new post can be used to track the work on Javascript inline-docs. The original post on the JS docs initiative can be found here. In this post I have excluded files that have already been completed.

At the bottom is a list of every first-party JavaScript file in core. Files with a checkmark have been patched and are considered completed. Files marked with (username #xxxxx) are already claimed, and being worked on.

Directly below is the process we’re using to make sure each of these files can get patched swiftly with no duplicated nor wasted efforts.

How to contribute

  1. Familiarize yourself with the JavaScript documentation standard, as well as the formatting guidelines and documenting tips.
  2. Check the list first to make sure the file you want to work on hasn’t already been claimed.
  3. Update your local WordPress SVN (use svn up) or Git repo (use git pull) to the latest version of WordPress trunk.
  4. Create a new ticket on Trac for the file.
    • Format the title as “JSDoc: path/to/file.js”.
    • The Type should be “defect (bug)”.
    • Assign the ticket to the component the file is associated with.
    • Leave the Version blank.
    • Add the docs and javascript focuses.
  5. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN or Git checkout.
  6. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

We’d like to welcome everyone to start contributing inline documentation! You can start contributing by picking a file from the list of unclaimed files below and claiming it in the comments. Please also see the JS docs handbook page for a step by step guide on how to get started.

Note: Note: To give everyone a chance to claim a file and to ensure the work proceeds as quickly as possible, please only work on one file at a time.

Determining the since version

We use JSDoc’s @since tag to indicate when a particular function was added to WordPress core. When you are documenting a function, you will also need to identify when that function was first introduced.

The recommended tool to use when searching for the version something was added to WordPress is svn blame. An additional resource for hooks is the WordPress Hooks Database. If, after using these tools, the version number cannot be determined, use @since Unknown.

If you use the git repository of WordPress you can also use git to determine the @since version. Either use git blame or the GitHub blame function. Once you have the commit hash which introduced a piece of code you can find out the version by using git tag --contains [commit-hash]. This will list all versions a certain commit has been shipped in. The lowest version is then what you put after the @since annotation.

Note: Make sure that the commit you found it the actual commit where a piece of code was introduced. JavaScript files have been moved around a lot in the past, so make sure to take that into account.

Note: All @since tags should follow the three digit x.x.x format.

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what we’re trying to do should take place during the weekly devchat. That’s either #core-js or #core.

Files needing patches:

Checked files are completed, marked files are claimed

  • src/js/_enqueues/wp/customize/controls.js (@jjcomack)
  • src/js/_enqueues/wp/customize/nav-menus.js
  • src/js/_enqueues/wp/customize/widgets.js
  • src/js/_enqueues/lib/gallery.js (@hunkriyaz)
  • src/js/_enqueues/admin/link.js (@andg)
  • src/js/_enqueues/lib/nav-menu.js
  • src/js/_enqueues/admin/plugin-install.js
  • src/js/_enqueues/wp/revisions.js
  • src/js/_enqueues/admin/set-post-thumbnail.js
  • src/js/_enqueues/wp/svg-painter.js
  • src/js/_enqueues/wp/theme.js
  • src/js/_enqueues/wp/updates.js
  • src/js/_enqueues/admin/user-profile.js
  • src/js/_enqueues/admin/widgets.js
  • src/js/_enqueues/deprecated/fullscreen-stub.js
  • src/js/_enqueues/wp/customize/base.js
  • src/js/_enqueues/wp/customize/loader.js
  • src/js/_enqueues/wp/customize/models.js
  • src/js/_enqueues/wp/customize/preview-nav-menus.js
  • src/js/_enqueues/wp/customize/preview.js
  • src/js/_enqueues/wp/customize/selective-refresh.js
  • src/js/_enqueues/wp/customize/views.js
  • src/js/_enqueues/wp/mce-view.js
  • src/js/_enqueues/wp/media/audiovideo.js
  • src/js/_enqueues/wp/media/editor.js
  • src/js/_enqueues/wp/media/grid.js
  • src/js/_enqueues/wp/media/models.js
  • src/js/_enqueues/wp/media/views.js
  • src/js/media/controllers/audio-details.js
  • src/js/media/controllers/collection-add.js
  • src/js/media/controllers/collection-edit.js
  • src/js/media/controllers/edit-attachment-metadata.js
  • src/js/media/controllers/embed.js
  • src/js/media/controllers/featured-image.js
  • src/js/media/controllers/image-details.js
  • src/js/media/controllers/library.js
  • src/js/media/controllers/media-library.js
  • src/js/media/controllers/region.js
  • src/js/media/controllers/replace-image.js
  • src/js/media/controllers/site-icon-cropper.js
  • src/js/media/controllers/state-machine.js
  • src/js/media/controllers/state.js
  • src/js/media/controllers/video-details.js
  • src/js/media/models/attachment.js
  • src/js/media/models/post-image.js
  • src/js/media/models/post-media.js
  • src/js/media/models/query.js
  • src/js/media/models/selection.js
  • src/js/media/routers/manage.js
  • src/js/media/utils/selection-sync.js
  • src/js/media/views/attachment-compat.js
  • src/js/media/views/attachment-filters.js
  • src/js/media/views/attachment-filters/all.js
  • src/js/media/views/attachment-filters/date.js
  • src/js/media/views/attachment-filters/uploaded.js
  • src/js/media/views/attachment.js (@digitalarticle)
  • src/js/media/views/attachment/details-two-column.js
  • src/js/media/views/attachment/details.js (@maartenleenders)
  • src/js/media/views/attachment/edit-library.js
  • src/js/media/views/attachment/edit-selection.js
  • src/js/media/views/attachment/library.js
  • src/js/media/views/attachment/selection.js
  • src/js/media/views/attachments/browser.js
  • src/js/media/views/attachments/selection.js
  • src/js/media/views/audio-details.js
  • src/js/media/views/button-group.js
  • src/js/media/views/button.js
  • src/js/media/views/button/delete-selected-permanently.js
  • src/js/media/views/button/delete-selected.js
  • src/js/media/views/button/select-mode-toggle.js
  • src/js/media/views/cropper.js (@kapteinbluf)
  • src/js/media/views/edit-image-details.js
  • src/js/media/views/edit-image.js
  • src/js/media/views/embed.js
  • src/js/media/views/embed/image.js
  • src/js/media/views/embed/link.js
  • src/js/media/views/embed/url.js
  • src/js/media/views/focus-manager.js
  • src/js/media/views/frame.js
  • src/js/media/views/frame/audio-details.js
  • src/js/media/views/frame/edit-attachments.js
  • src/js/media/views/frame/image-details.js
  • src/js/media/views/frame/manage.js
  • src/js/media/views/frame/media-details.js
  • src/js/media/views/frame/post.js
  • src/js/media/views/frame/select.js
  • src/js/media/views/frame/video-details.js
  • src/js/media/views/iframe.js
  • src/js/media/views/image-details.js
  • src/js/media/views/label.js
  • src/js/media/views/media-details.js
  • src/js/media/views/media-frame.js
  • src/js/media/views/menu-item.js
  • src/js/media/views/menu.js
  • src/js/media/views/modal.js
  • src/js/media/views/priority-list.js
  • src/js/media/views/router-item.js
  • src/js/media/views/router.js
  • src/js/media/views/search.js
  • src/js/media/views/selection.js
  • src/js/media/views/settings.js
  • src/js/media/views/settings/attachment-display.js
  • src/js/media/views/settings/gallery.js
  • src/js/media/views/settings/playlist.js
  • src/js/media/views/sidebar.js
  • src/js/media/views/site-icon-cropper.js
  • src/js/media/views/site-icon-preview.js
  • src/js/media/views/toolbar.js
  • src/js/media/views/toolbar/embed.js
  • src/js/media/views/toolbar/select.js
  • src/js/media/views/uploader/editor.js
  • src/js/media/views/uploader/inline.js
  • src/js/media/views/uploader/status-error.js
  • src/js/media/views/uploader/status.js
  • src/js/media/views/uploader/window.js
  • src/js/media/views/video-details.js
  • src/js/media/views/view.js
  • src/js/_enqueues/lib/quicktags.js
  • src/js/_enqueues/wp/shortcode.js (@hanopcan)
  • src/js/_enqueues/lib/cookies.js
  • src/js/_enqueues/wp/a11y.js
  • src/js/_enqueues/lib/ajax-response.js
  • src/js/_enqueues/wp/api.js
  • src/js/_enqueues/lib/auth-check.js (@pskli)
  • src/js/_enqueues/wp/custom-header.js
  • src/js/_enqueues/lib/embed-template.js
  • src/js/_enqueues/wp/embed.js
  • src/js/_enqueues/wp/emoji.js (@igorsch, @nicollle)
  • src/js/_enqueues/lib/list-revisions.js
  • src/js/_enqueues/lib/lists.js
  • src/js/_enqueues/lib/pointer.js (@maartenleenders)
  • src/js/_enqueues/wp/util.js
  • src/js/_enqueues/lib/link.js

Current status:

Happy documenting!

#inline-docs

#javascript

Dev Chat Agenda: June 13th (4.9.7 week 4)

This is the agenda for the weekly dev meeting on June 13, 2018 at 20:00 UTC / June 13, 2018 at 20:00 UTC:

  • 4.9.7 planning
  • Updates from focus leads and component maintainers
  • Devchat coordination
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-7, #agenda, #core, #dev-chat

PHP Meeting Recap – June 4th

This recap is a summary of our last PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • The recap continued the discussion from last week (read the recap) about how to prevent plugin installations from happening if the plugin requires a WordPress or PHP version that is not met by the environment (see #43986 for the related ticket).
  • First it was discussed how to display the notice to inform the user of the version requirement not being met. @melchoyce had presented several design approaches for it, with the aftermath of last week’s meeting highlighting a mockup that replaces the bottom section of the plugin card with the red notice.

Plugin search result: "Incompatible plugin" error

  • The majority of voices during the meeting voted for using the above design, mostly for its clear highlighting and available space. Concerns were expressed about not showing specific PHP versions and, more specifically, about hiding the stats about ratings and active installations. The latter are completely unrelated, so the above mockup may need to be adjusted to include the stats as they are displayed on regular plugin cards at this point. This will need to be re-evaluated in the next meeting.
  • The other point discussed were the copy to use for the notice, including a link to show to solve the problem. The following copy was agreed on for the two respective issues:

    Incompatible with your version of WordPress. Please update WordPress (link to update WordPress).

    Incompatible with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • The above copy is brief and on point, and contains a clearly-described link as a call-to-action, being much more accurate than the previous “Why” links. It was decided to not include specific WordPress or PHP versions in this notice because these version numbers are more technical and would be unnecessary information for most users. Only the “More Details” modal should provide them. The copy was agreed on to use during the meeting, however with a concern being expressed later about the strict tone resulting of the short length of the structurally incomplete sentence. The following alternative was suggested:

    You can’t install this plugin because it doesn’t work with your version of WordPress. Please update WordPress (link to update WordPress).

    You can’t install this plugin because it doesn’t work with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • It was agreed that this copy sounds better, but it would need to be figured out how to fit it into the small space available. Alternatively, the longer variant could only be used for the notices displayed in the More Details modal. On the other hand, that would make visibility of these seemingly friendlier notices much lower. The copy can likely be finalized in next week’s meeting.
  • A problem that was not clearly handled yet is what should happen if both the WordPress and PHP versions are insufficient. In that case, either both sentences could show, increasing the required space further and possibly looking strange due to a single notice showing content that looks like two actual notices. On the “More Details” modal this is not a problem, but it may need a solution on the plugin cards.
  • An alternative was suggested to, at least on the plugin card, always only mention one of the two problems, even if both occur. While none of the participants were really satisfied with that approach, they agreed that in such a case the WordPress version issue should take precedence because it is most likely much easier to fix. The discussion on how to deal with both issues occurring simultaneously should be continued once it is clear how to display the notice and what content to use. It may very well be solved in that process as it needs to be considered for both decisions.

While the preliminary decisions made during the meeting are certainly not final, @afragen implemented the state after the meeting in an updated patch and provided screenshots for it on the ticket, which can help a lot in evaluating the possible approaches in the upcoming meetings.

Next week’s meeting

  • Next meeting will take place on Monday, June 11, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on how to display the notice, with particular attention to maintaining the information currently present on the plugin card and accounting for the possibility of both versions being insufficient. The concrete copy to use should only be discussed if there is enough time left at the end.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summary

Changes that Affect Theme Authors in WordPress 4.9.6

Update 5/18: Added note about privacy policy management on multisite installs.
Update 5/17: Added details about themes passing the fields argument to comment_form().

In WordPress 4.9.6, several tools were introduced to help sites meet the requirements of the new European Union’s new GDPR (General Data Protection Regulation) laws. This post will detail what theme authors need to know about compatibility with the new features.

Theme authors should test their themes to confirm that there are no design conflicts between the new features and their themes detailed below.

Privacy Policy Pages

WordPress 4.9.6 introduced the ability to easily select a page as a privacy policy for a site in the Settings > Privacy section of the admin area (#43435). For new sites, a privacy policy template page will automatically be created in draft status (#43491).

To easily link to the selected page in plugins and themes, three template tags have been added (#43850):

  • get_privacy_policy_url() – Retrieves the URL to the privacy policy page.
  • the_privacy_policy_link() – Displays the privacy policy link with formatting, when applicable.
  • get_the_privacy_policy_link() – Returns the privacy policy link with formatting, when applicable.

Note: On multisite installs, only super admins are allowed to manage privacy policies. If one policy is desired for the entire multisite, the `privacy_policy_url` filter can be used to accomplish this. See #43919.

Example

The following example will display the privacy policy link surrounded by a <div>.

if ( function_exists( 'the_privacy_policy_link' ) ) {
        the_privacy_policy_link( '<div>', '</div>');
}

Commenter Cookie Opt-Ins

When a logged out user comments on a post, they are asked for their name, email, and website. This information is stored locally in the commenter’s browser for two purposes:

  1. When they leave another comment on the site, their name, email, and website will be pre-populated into the respective fields.
  2. If their comment is held for moderation, they can return to that post and remove the comment before it is approved.

The information stored in this cookie is for convenience and is not essential. Therefore, the user needs to be given the choice to opt in or opt out of the storage of this data.

For this reason, a checkbox has been added to the comment form that allows commenters to opt-in to storing this data in the cookie. This checkbox will be unchecked by default, as opt-in is an action the user must explicitly approve.

The new checkbox field is automatically added to comment forms displayed using the comment_form() function inside a p.comment-form-cookies-consent element.

While most themes will not require any action, it is recommended that you double check that the new input and label does not require CSS adjustments in custom themes.

For more information on this change, check out #43436 on Trac,

Themes Overriding Comment Forms

By default, WordPress automatically displays the new checkbox field discussed above. However, if a theme is passing the fields argument to the comment_form() function, the field will not display and needs to be added to the list of fields.

Example

The following example will only display the email field above the comment message field in the comments form.

comment_form(
	array(
		'fields' => array(
			'email' => 'field markup',
		),
	)
);

After updating, the new comment opt-in field will need to be added.

comment_form(
	array(
		'fields' => array(
			'email' => 'field markup',
			'cookies' => 'opt-in field markup',
		),
	)
);

The default markup for the field can be found in wp-includes/comment-template.php.

A second option for fixing this would be to utilize the comment_form_default_fields filter instead. Using this filter, default comment fields can be added or removed without having to pass the fields argument to the function.

Bundled Themes

All 8 currently supported bundled themes (Twenty Ten-Twenty Seventeen) have been updated to support these changes. Site footers will display a link to the site’s privacy policy when one has been selected (#43715), and the commenter cookie opt-in field has been styled.

Child themes built on top of bundled themes should be checked to see if any adjustments are necessary for the privacy policy link in the footer.

Dev Chat Agenda: May 23rd (4.9.7 week 1)

This is the agenda for the weekly dev meeting on May 23, 2018 at 20:00 UTC / May 23, 2018 at 20:00 UTC:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-6, #4-9-7, #agenda, #core, #dev-chat

PHP Meeting Recap – May 28th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We started with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

4.9.6 Update Guide

Included in WordPress 4.9.6 are several new functions and tools that you should be aware of. Here is a brief breakdown of resources to help you become acquainted with WordPress 4.9.6.

Attention: Theme Authors

4.9.6 adds several new privacy related features, one of which may require a small styling adjustment. These are detailed in the following dev note.

Changes that Affect Theme Authors in WordPress 4.9.6

Privacy

WordPress 4.9.6 introduces some new tools related to data privacy. This includes a tool for users to request an export of all the stored data associated with them on the site. It also includes a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests.

To help plugin and theme authors integrate with these new tools, several new pages in the Handbook have been created.

Suggesting text for the site privacy policy
Adding the Personal Data Exporter to Your Plugin
Adding the Personal Data Eraser to Your Plugin
Privacy Related Options, Hooks and Capabilities

New PHP Polyfills

To help WordPress Core, plugins, and themes with forward compatibility, a polyfill for each of these functions has been added in 4.9.6. When a site is not running a version of PHP that includes these functions, WordPress will automatically load these polyfills.

New PHP Polyfills in 4.9.6

TinyMCE Update

TinyMCE has been updated from version 4.6.7 to version 4.7.11. This update provides a large number of bug fixes. For more information, see #43862.

A full list of bugs and enhancements in 4.9.6 can be found on Trac.

#4-9-6, #field-guide

Dev Chat Summary: May 30th (4.9.7 week 2)

This post summarizes the dev chat meeting from May 30th (agenda, Slack archive).

4.9.7 planning

  • No pressing need for quick 4.9.7 release, so aiming for ~6-8 week release cycle for 4.9.7
  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, and @tristangemus open to help contribute during 4.9.7
  • Please comment on this post, ping @jeffpaul, or comment during the next dev chat for nominations (self or otherwise) for release leads on 4.9.7

Updates from focus leads and component maintainers

  • The PHP team posted a summary from their meeting last week covering the “Upgrade PHP” page and possible Gutenberg blocks. Please join them this coming Monday, June 4th at 15:00 UTC in #core-php
  • The GDPR Compliance team met earlier today and of note will be changing the Slack channel and post tags to Core Privacy this Friday, June 1st. Please join them next Wednesday, June 6th at 15:00 UTC in #core-privacy

Guidelines for fixing coding standard violations

  • Now that r42343 has landed, Core is accepting patches to fix coding standards (CS) violations. The meeting attendees agreed on the following guidelines:
    • Patches for any CS fixes are welcome, as long as they’re not so extensive that it would require refreshing an unreasonable amount of regular patches.
    • In order to avoid wasting time, patches for violations which cannot be automatically fixed by `phpcbf` should be given preference over ones that can be automatically fixed.
    • Regardless of many files are touched in a CS patch, the corresponding commits should be limited to fixing a single file in each commit.
    • CS patches should be treated just like any other patch, and reviewed critically before being committed. That also applies to any changes made by `phpcbf`.
    • Commits for new features, bug fixes, and other “logic” changes should not include unrelated CS fixes. Coding standards fixes should be done in a separate commit. If a line is already being changed to fix a bug, etc, then it should have CS violations fixed at the same time. If fixing the violation for that line would introduce changes beyond that line, though, then the CS fixes should be done in a separate commit.
  • Does anyone strongly object to those, before they’re added to Handbook?

General announcements

Next meeting

The next meeting will take place on June 6, 2018 at 20:00 UTC / June 6, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-7, #core, #core-php, #core-privacy, #dev-chat, #gdpr-compliance, #summary, #wpcs