Labeling Issues in the Gutenberg Project

Hello! I will be working closely with Gutenberg for the next several months and am really pleased to be here!! My WordPress username is designsimply and I go by sheri on Slack.

Part of my work is centered around bug gardening where my goal is to scrub bugs to fit the project’s workflow in a way that saves everyone else time by adding screenshots, checking validity, closing inactives, and sane labeling. Labels are important for historical reference too, so any work here should prove useful as the project grows!

Labeling rules I tend to follow:

  • Each issue should have a focus area and type label.
  • Each PR should have a focus area and status label.
  • Priority labels should only be set as needed—just using high and low is 👍.
  • High priority issues should have an assignee or be in an active milestone.
  • Action-based labels start with “Needs”.

I’ve made a few small changes to labels so far:

  • Added [Type] Duplicate (for tracking and so dupes can easily be filtered out of searches).
  • Combined [Type] Support and [Type] How do I? and renamed to [Type] Help Request.

Have I mentioned I love labels?! Let’s update them together as an iterative process. Deciding labels can be opinionated so open discussions about them will be fun and help us work together in good ways.

My next questions about labels:

  1. Can we move Chrome and UI Components to something like Block Controls?
  2. Can we move [Type] Plugin / Theme Interoperability to [Type] Plugin Conflict and [Type] Theme Conflict?
  3. Should Won't Fix and Works For Me be [Type] labels?
  4. I’d love to add Design Notes label as a way to track design decisions.
  5. What is [Type] WP Core Bug for exactly?
  6. Should Text Mode be changed to Edit as HTML to match the UI?
  7. Can we get rid of [Status] Stale in favor of closing?
  8. Let’s use [Status] Needs More Info or close with a comment instead of Works For Me.
  9. Would it be useful for devs to add [Status] Revisit to issues that are not good to keep open now but may be good to look at again in the future?

If you’re keen to help with Gutenberg bug gardening or discuss the inner amazingnesses of labeling 😊, then I would love to talk with you! Please comment here or say hello in #core-editor on Slack.

What’s New in Gutenberg? (6th July)

This release generally completes our MVP feature set for the editor by adding inline images, block style variations, and a new columns approach. Switching focus to bugs, enhancements, compatibility, and API stability from now on. Worth noting that there’s people working on some more individual blocks (a few widgets and playlist) to be included when ready.

The most significant addition is block style variations. This will allow registration of alternate styles (based on class names) for any block, with automated real thumbnails and live previews built in to the block transformation tool. We have added them to the Quote, Button, and Separator blocks for illustration. The public API will be exposed in a future release.

Block Style Variations

3.2 🥚

All Updates

PHP Meeting Recap – June 25th

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 first discussed terminology: are we talking about “PHP upgrades” or “PHP updates“? We are currently mixing both of these in a rather random fashion. We then decided that we’ll stick to “PHP updates” and “updating PHP” from now on, because:
    • The distinction between “update” and “upgrade” is lost on most users anyway, so we should only use one in user communication.
    • “Upgrade” implies an improvement. An “update” means getting it to the latest state. While it will provide improvements, doing an “update” is actually what we’re after, even if no improvements are to be had.
    • “Update” better fits with the rest of WP communication as well.
  • The following changes will be made to make all project deliverables consistent with the above decision:
    • Patches in #43986, #43987 and #44350 will be changed to only refer to “updates”.
    • The core capability upgrade_php will be renamed into update_php.
    • The support page will be renamed from Upgrading PHP to Updating PHP, and the page’s content will be adapted accordingly.
    • The support page’s URL will be changed to https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
    • A redirect will be done from https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
  • Then we quickly discussed the #design <=> #marketing collaboration with @jaymanpandya and @alexdenning. They have already made contact and will keep us updated on their collaboration progress.
  • Finally, we discussed our new goal of “sandboxing” the plugin/theme’s PHP code in some way to make sure users cannot be locked out of their site through a white-screen-of-death (WSOD).
  • Current observations:
    • Exceptions don’t help, as they are not fully integrated into the error handling at PHP 5.2.
    • We can use a shutdown handler to detect fatal errors and know where they were triggered: https://3v4l.org/4jWAs .
    • Such a shutdown handler could record a fatal error, and the next page request could then detect a recorded fatal error and decide based on some heuristics whether to initiate “safe mode”
    • We cannot just act on plugin activation/deactivation, as this will still take the site down if we update PHP.
    • We cannot disable a single plugin, as we cannot reliably detect who the actual culprit is in all cases.
    • We might be able to disable a single plugin in those cases where we hit a parse error in a file of a plugin.
  • A Trac ticket was created for this: #44458 – Catch WSODs and provide a means for recovery for end users

Next week’s meeting

  • Next meeting will take place on Monday, July 2nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on the avoiding WSODs in PHP.
  • 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

WordPress Privacy Chat Agenda – June 20

Agenda proposal:

  • Stats (Trac tickets)
  • Roadmap
  • Feedback from WCEU Contributor day and the workshop
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#core-privacy, #agenda

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

WordPress Privacy Chat Agenda – June 06

Agenda proposal:

  • Welcome to new contributors
  • Info: Name change: slack channel, GitHub repository
  • Stats: Trac tickets stats
  • Roadmap
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#core-privacy, #agenda

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

GDPR Compliance Chat Agenda – May 30

Note: GDPR Compliance will be renamed to Core Privacy on June 1. The slack channel and post tags will be adapted accordingly.

Agenda proposal:

  • Info: Name change
  • Stats: Trac tickets stats
  • Info: Weekly bug scrub
  • Roadmap v2, v3
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #core-privacy, #agenda

GDPR Compliance Chat Agenda – May 23

Agenda proposal:

  • 4.9.6 vs 4.9.7 and 4.9.8
  • Roadmap v2
  • Ticket prioritization 
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #agenda

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