What’s new in Gutenberg? (20th July)

Today’s release continues to improve multiple areas of Gutenberg, its behaviours and tools. Most of the updates are around refining the experience and strengthening the API surface, but there’s also a couple new server rendered blocks added to the library. There are also multiple packages being extracted as the APIs mature. Many thanks again to all the contributors!

Archives and Recent Comments blocks

3.3 🥝

Deprecations removed with this version.

Source: WordPress Development Updates

WordPress 4.9.8 Beta 2

second beta package for 4.9.8 has been released and is now available for testing. Please help test this beta version to ensure everything works as expected.

This package contains 1 blessed task, 3 bug fixes and 3 enhancement since the first beta. This brings the total number of bug fixes in 4.9.8 to 25, enhancements to 11 and blessed tasks to 3.

Important Note: This second beta includes the “Try Gutenberg” callout.

The release candidate is scheduled for Tuesday, July 24th  and final release is scheduled for Tuesday, July 31st.

Blessed Tasks

A full list of blessed tasks in 4.9.8 Beta 2 can be found on Trac.

The tickets listed below are only those committed since Beta 1 was released.


  • #41316 – Introduce “Try Gutenberg” callout

Bug Fixes

A full list of bugs fixed in 4.9.8 Beta 2 can be found on Trac.

The tickets listed below are only those committed since Beta 1 was released.


  • #44574 – Saratov and other cities missing from translations


  • #44192 – Title of Privacy Policy Page not used on login page
  • #44130 – Mixed Case of Privacy Policy on Privacy Settings page


A full list of enhancements in 4.9.8 Beta 2 can be found on Trac.

The tickets listed below are only those committed since Beta 1 was released.

Options, Meta APIs

  • #38323 – Reconsider $object_subtype handling in `register_meta()`


  • #43967 – Admin emails after email confirmation don’t work for data privacy requests
  • #44612 – Grammar – Missing ‘a’ in ‘select new Privacy Policy page’

#4-9-8, #release

Source: WordPress Development Updates

Dev Chat Agenda: July 18th (4.9.8 week 3)

This is the agenda for the weekly devchat meeting on July 18, 2018 at 20:00 UTC.

  • 4.9.8 update from release leads:
  • Updates from focus leads and component maintainers.
  • 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!

Source: WordPress Development Updates

WordPress 4.9.8 Beta 1

It’s that time again, we have a new beta release package for 4.9.8, and we’d love your help testing it out. It’s important to make sure that a release is fully tested and bugs are squashed. If you’re new (or it’s been a while) you can checkout the guide for helping to test a beta version.

This beta release contains 21 bug fixes, 9 enhancements and 2 blessed tasks. The purpose of this release has been to focus on additional enhancements for privacy in WordPress (following up on the tremendous work done for 4.9.6), as well as adding a callout to try the new Gutenberg editing experience.

The work being done to introduce the “Try Gutenberg” callout (#41316) is still in progress, and as such hasn’t been included in this first beta. Our plan (subject to change) is to release a second beta version once that’s ready, and once that hits we’ll ask for specific testing on the callout.

For the rest of the work, we’d love your help to make sure the enhancements and bug fixes are working as expected!

The release candidate is scheduled for Tuesday, July 24th, and the official release is scheduled for Tuesday, July 31st.

Bug Fixes

A full list of bugs fixed in 4.9.8 Beta can be found on Trac.

Bundled Theme

  • #44109 – TwentySeventeen backend editor: level 2 bulleted lists nested under numbered lists show numbers instead of bullets


  • #44141 – Privacy: Don’t replace comment author URL and email with anything
  • #44342 – Commenter cookie consent message should not be displayed if the cookie action isn’t hooked


  • #44104 – Customize: Attempt to count uncountable value


  • #44341 – Replace _deprecated_function( ‘add_filter’ ) with apply_filters_deprecated()

Filesystem API

  • #43054 – wp_is_stream fails with stream definition containing nonascii chars

Login and Registration

  • #44052 – Missing parameter type for `login_header()`


  • #43751 – REST API: Attachments controller should respect “Max upload file size” and “Site upload space” in multisite
  • #44532 – Extreme memory leak related to wp_is_stream in wp-includes/functions.php in WordPress 4.9.7


  • #44099 – Add Request Type into Admin Email Subject for GDPR
  • #44195 – “Silence is golden” index.html generates output
  • #44265 – Add filter for email subject for erasure complete notification
  • #44353 – Replace `site_url( ‘wp-login.php’ )` in `wp_send_user_request()`
  • #44379 – GDPR filters should provide either $request or $request_id
  • #44382 – Filter the subject within _wp_privacy_send_request_confirmation_notification
  • #44396 – Inconsistent use of blogname and sitename in Privacy emails
  • #44590 – Remove “// WPCS:” comments

Rest API

  • #43874 – REST API: Only render fields specific to request when _fields= is used
  • #42691 – WP_Term_Query get_terms generates invalid sql queries
  • #44096 – REST API: Taxonomy and term endpoints should use correct permission checks
  • #44330 – TinyMCE: do not force-load external TinyMCE plugins


A full list of enhancements in 4.9.8 beta can be found on Trac.

Posts, Post Types

  • #36085 – Add action hook to get_inline_data()


  • #44006 – Privacy Policy page should have suffix like other special pages
  • #44025 – Privacy: Pagination screen options for the requests list tables
  • #44100 – GDPR Privacy Page setting allows for Draft Pages
  • #44131 – If draft page selected for Privacy Policy page should verbiage change from view to preview
  • #44181 – The input field id username_or_email_to_export should be something else on remove_personal_data page
  • #44373 – Add a privacy setting to disable comment cookie consent
  • #44321 – REST API: Expose revision count and last revision ID on Post response
  • #44287 – REST API: Declare user capability to perform actions using JSON Hyper Schema `targetSchema`

Blessed Tasks

A full list of blessed tasks in 4.9.8 beta can be found on Trac.


  • #44339 – Emoji: Update Twemoji to 11.0


  • #44134 – Update to TinyMCE 4.7.13
    • See the TinyMCE changelog.  WP 4.9.6 included TinyMCE 4.7.11, WP 4.9.8 beta 1 updated to TinyMCE 4.8.0.

#4-9-8, #release

Source: WordPress Development Updates

Servehappy: Roadmap Update and Priorities

At WordCamp Europe 2018, representatives from different teams got together to discuss the state of the Servehappy project, reevaluate its roadmap and priorities.

Meeting Context

While this blog typically contains updates from the core PHP team, it is important to highlight that the Servehappy project is an interdisciplinary effort that has involved several other teams as well. We have been collaborating closely with the marketing and design teams so far, however at the same time several efforts were pursued in other teams which had not been mentioned as much in the weekly recap posts: The community team and support team have been pushing a format called “Site Health Check”, providing support services at WordCamps to increase adoption of modern PHP versions as a part of that. The hosting team has also discussed on how to approach the problem on their end. Due to all these different teams being involved in the Servehappy project, we wanted to revisit the project state together with a representation of those teams.

Participants: @alexdenning, @flixos90, @mikeschroder, @miss_jwo, @pento, @schlessera

Meeting Summary

Short-Term Goals

While the general long-term goals of the project are clear and available in the project’s roadmap, the discussion briefly involved clarifying priorities and short-term goals.

  • Increase adoption of modern PHP versions by being more active and vocal about the necessity of those.
  • Encourage users in a positive manner to update and stay updated.
  • Make the process of updating as seamless as possible.
  • Release a first iteration of the project that warns administrators of sites running PHP 5.2.

Approach: Help People

We agreed that, in line with the WordPress philosophies, the approach to solving the problem should be based on framing the project in the user’s context, most of who have little to no technical knowledge of PHP.

  • We would like to boost user confidence by encouraging the update and educating about preliminary recommended steps to take in order to ensure the process goes without a hassle.
  • By highlighting tools such as Tide, the Health Check plugin, or the PHP Compatibility Checker plugin, we allow non-technical users to easily gain technical insights in a plugin’s compatibility with certain PHP versions.
  • We intend to reduce the risk of updating PHP as much as possible by implementing a sandboxing system to decrease the chance of a site breaking through the update. We need to ensure that site owners are never locked out of the backend due to an incompatibility.
  • We plan to run further Site Health Check desks at WordCamps and related events and encourage organizers to do so, in order to raise awareness of the importance of checking the PHP version on your website. An important side note to this, at this point only updates to PHP 7.2 and 7.1 should be encouraged, as both PHP 5.6 and 7.0 will be unsupported from the end of this year.

Data about PHP Version Updates

We briefly talked about the jumps from and to specific PHP versions, looking at how involved they typically are.

  • The update from 5.2 to 5.3 has known issues which are not small. We should review the support impact for hosting companies, agencies, plugins, themes, and the WP.org support team.
  • The updates between 5.3 to 5.6 are usually unproblematic, there have been no known major issues.
  • The update from 5.6 to 7.0 has many known issues. @mikeschroder will request a list of common issues and errors known to the hosting team when performing that update.
  • The updates between 7.0 and 7.2 have been less problematic, however due to several deprecations more investigations should be made in that area.

Improving the Updating PHP Page

While the nag to inform site owners about an unsupported PHP version has already been merged into core and an Updating PHP page is already available, it is necessary to improve the latter.

  • The above page, which is linked to from the core nag, will to a large extend determine whether the project will be successful or not, as people have to be willing to read its content and then act on its recommendations.
  • Currently the page is a simple wall of text, which will likely scare away visitors. The page content needs to be further reworked, broke down into more obvious sections, shortened, and be visually enhanced so that users are guided through the process as intuitively as possible.
  • @alexdenning will coordinate with @jaymanpandya who had worked on a design for the page before to move this forward.

Community Plans

  • A Site Health Check desk will be available at WordCamp Brighton in mid-August with the goal of testing this approach further and optimizing the process.
  • Following this, we would like documentation to be created about having this format, with the goal of it being ready by WordCamp US in early December. That documentation could then be shared with communities and organizers around the world, encouraging providing this format at more events.
  • Current plans also include there being a Site Health Check desk at WordCamp US, preferably also with more hosting team support at the desk, especially due to their high availability at that event.
  • Another idea was to have wapuus made available specifically for the Site Health Check.

Hosting Plans

  • The core PHP team would like to communicate more and collaborate more closely with the hosting team.
  • The hosting team is an ally to these efforts and would like to be more involved. Some miscommunications in the past were figured out and clarified.
  • It is planned that a representative of the hosting team will be participating in the weekly PHP team meetings, reporting back and voicing views of the hosting team on the topics discussed. As of now, @antpb has stepped up to fill that position.
  • It would be great if documentation for hosting companies could be created on how to integrate with the Servehappy nag in core (read more about the core integration) and on how to provide easy-to-understand documentation on how to safely update PHP in their specific environment.
  • An idea for further down the road that came up was having standardized endpoints as part of an API for upgrading PHP across hosts. CPanel or Plesk adopting this could move the needle across many hosts at once.

Core and Security Plans

  • The security and core teams plan to work on user-facing documentation on why running old versions of PHP or WordPress is dangerous.
  • Furthermore they intend to create documentation for both plugin and theme authors about how to ensure that their code is compatible with modern PHP versions.

Involvement of the Marketing Team

  • Going forward, all documentation created as part of the aforementioned plans should preferably be reviewed by the marketing team.
  • It is important to use an easy-to-understand, encouraging and positive tone of voice for all documentation.
  • We need to ensure that all marketing material documentation is localizable and uses language that is easily translatable.

Requirements for Servehappy in Core

In order for the first iteration of the Servehappy project to be shipped in a core release, we determined the steps that must be completed before.

  • The first iteration should primarily revolve around the core nag warning users about outdated PHP versions. It will only be displayed for PHP 5.2 in the first iteration.
  • Due to that version being controlled by a wordpress.org API, the nag’s visibility can be gradually increased by being shown on higher PHP versions too, without being tied to WordPress core releases.
  • Further efforts of the Servehappy project in core, such as preventing installation or updates of incompatible plugins and themes, are not specifically a requirement for the first iteration. Although not as high a priority at this point, they should definitely not stall and will be merged and released as they get completed, however only at the same time or later than the core nag.
  • The efforts of improving the Updating PHP page mentioned above needs to be completed, with the page being in a solid state. It should be fully translatable, and there should be enough time before the release to encourage the creation of localized versions of the page across the globe. The link to the page in core is localizable as well, being able to link to those versions.
  • A safe-mode functionality needs to be implemented in order to prevent WSODs (white screens of death) and other errors that would lock the site owner out of their backend. It will likely involve some sort of sandboxing system, with plugins being deactivated in the admin as necessary to ensure possible access. Having this will allow the instructions in the Updating PHP page to be more positive and confirming. @schlessera has since been making quite a bit of progress on this already in #44458.
  • It should be possible for hosting companies to hook into the nag and provide their own instructions of how to upgrade to WordPress users on their stack.
  • It is currently envisioned to have the first iteration ship as part of WordPress 5.0, however depending on when that version is released, this may change. It is certainly no hard deadline in that regard.

Project Name Proposal

  • Based from the Site Health Check desks, there is a suggestion to refocus the project to be the WordPress Health Check Project which encourages people by name to check for updates continually.
  • However, the problem has arised about defining what is in scope of the site health check. It needs to be clarified what kind of health check this is, as some users so far have looked at it as a performance check.
  • The name change would allow for a more positive mindset and for the scope of the project to change as the WordPress project needs it to.
  • Unless there are objections, the name Servehappy for the core efforts is solely an internal codename and will not be exposed to the user anywhere.

Get Involved

If you’re interested in these efforts, please get involved and get in contact with the respective team whose work you are interested in. The easiest way to do so is participate in their meetings. We need your input and ideas, specifically we would like to ask for your feedback on the outcome of the discussion that is part of this summary, as most of it is not set in stone. If you cannot make it to the respective meeting, posting a comment here is a great alternative.

As far as the core efforts go, the next meeting will take place on Monday, July 23th, 2018 at 15:00 UTC in the #core-php channel on Slack.

Source: WordPress Development Updates

Javascript Chat Summary – July 17th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Attending: @abdullahramzan@adamsilverstein@aduth@gziolo@herregroen@hypest, @andrei.lupu, @netweb@rheinardkorf, @tofumatt, @soen, @chopinbach, @nerrad, @youknowriad

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda Item: Versions of Node and NPM used in WordPress projects

Slack Conversation

This agenda item focused around discussing what versions of Node and NPM is used in WordPress projects and specifically within the context of what can be worked with within WordPress.org build platform constraints.

The current request can be tracked here.


What? Who?
Request from systems making available node 10/npm 6.
This will be in use until October and at that point, the operating policy will be using the LTS version of Node plus whatever NPM ships with that version.
Update various configuration/settings files in Gutenberg and wordpress-develop: .nvmrc, package.json, engines (etc). @netweb

Agenda Item: Packages

Slack Conversation

Some new packages have been merged to Gutenberg (not published at time of meeting):

  • @wordpress/html-entities
  • @wordpress/viewport
  • @wordpress/compose
  • @wordpress/components
  • @wordpress/api-fetch

There was discussion around the publishing process and improving it which includes moving towards automating some of the publishing process (which includes adopting conventional commits).  

Further discussion on this topic can be tracked via this Github issue.


What? Who?
Continue to identify and work on improvements to the publishing process that get it to “automating as much as possible as soon as possible”.  

Agenda Item: New compose package

Slack Conversation

The idea is to define precisely what should and shouldn’t go in each package without ending up with a catch-all components package.  The result is:

  • element: just the base API to build elements and components.
  • compose: a set of UI-less higher-order components and functions that can be used to build other components.
  • components: A set of UI-related components and higher-order components. 

Longer term this can be seen as Pattern library for WordPress.

Roadmap for this package structure can be found here.

Agenda Item: Proposal to extract Gutenberg’s ESLint configuration to a new module

Slack Conversation

Reference: Github pull request for proposal

Discussion took place around whether the current proposal should be called a “WordPress Standard Configuration”.  There was opposition expressed to the PR in its current form.


What? Who?
Between now and next meeting there needs to be assembled a detailed set of divergences that need to be proposed for consideration.
Post published proposing changes outlined from the above discovery process to Make/Core @aduth
Decision made on submitted proposal (involving wider WP team). 
This means no configuration will be published until this decision.

Source: WordPress Development Updates

Quarterly Updates | Q2 2018

To keep everyone aware of big projects and efforts across WordPress contributor teams, I’ve reached out to each team’s listed representatives. I asked each of them to share their Top Priority (and when they hope for it to be completed), as well as their biggest Wins and Worries. Have questions? I’ve included a link to each team’s site in the headings.


  • Contacted: @rianrietveld, @joedolson, @afercia
  • Priority: Working to make sure that Gutenberg is reasonably accessible prior to merge. ETA is before 5.0
  • Struggle: Lack of developers and accessibility experts to help test and code the milestone issues. The team is doing outreach to help solve this problem.
  • Big Win: Interest from companies like The Paciello Group and Tenon.io to help out with Gutenberg code review and testing tools.


  • Contacted: @danielbachhuber, @schlessera
  • Priority: Very first global Hack Day is coming up July 20. Version 2.0.0 is still in progress (new ETA is end of July).
  • Struggle: The team continues to need new contributors. The current team is tiny but tough.
  • Big Win: WP-CLI is currently one of the project’s four main focuses, as mentioned in the Summer Update at WordCamp Europe.


  • Contacted: @francina, @hlashbrooke
  • Priority: Focusing on smoothing out the processes in our community management by building up our team of volunteers and establishing what tools we need to keep things running well. ETA is ongoing.
  • Struggle: Our two biggest struggles at the moment are tracking what we need to get done, and making final decisions on things. There is current work on the tools available to assist with tracking progress.
  • Big Win: After making a concerted effort to get more contributors on the Community Team, we now have a much larger group of volunteers working as deputies and WordCamp mentors


  • Contacted: @jeffpaul
  • Priority: Following the WordCamp Europe summer update (and the companion post here), the team is getting Gutenberg (the new WordPress editing experience) into a strong state for the 5.0 release. Potential ETA as soon as August.
  • Struggle: Coordinating momentum and direction as we start seeing more contributors offering their time. Still working our way through open issues. The team is starting multiple bug scrubs each week to work through these more quickly and transparently.
  • Big Win: Had a sizable release in 4.9.6 which featured major updates around privacy tools and functionality in Core.


  • Contacted: @melchoyce, @karmatosed, @boemedia, @joshuawold, @mizejewski
  • Priority: Better on-boarding of new contributors, especially creating better documentation. ETA is end of July.
  • Struggle: It’s hard to identify reasonably small tasks for first-time contributors.
  • Big Win: The team is much more organized now which has helped clear out the design backlog, bring in new contributors, and also keep current contributors coming back. Bonus: Joshua Wold will co-lead the upcoming release.


  • Contacted: @kenshino
  • Priority: Opening up the work on HelpHub to new contributors and easing the onboarding process. No ETA.
  • Struggle: Some blockers with making sure the code and database can be ready to launch on https://wordpress.org/support/
  • Big Win: The first phase of HelpHub creation is complete, which means content updates (current info, more readable, easier discovery), internal search, design improvements, and REST API endpoints.


  • Contacted: @mikeschroder, @jadonn
  • Priority: Preparing hosts for supporting Gutenberg, especially support questions they’re likely to see when the “Try Gutenberg” callout is released. ETA July 31st, then before WordPress 5.0
  • Struggle: Most contributions are still made a by a small team of volunteers. Seeing a few more people join, but progress is slow.
  • Big Win: New team members and hosting companies have joined the #hosting-community team and have started contributing.


  • Contacted: @bridgetwillard
  • Priority: Continuing to write and publish case studies from the community. ETA is ongoing.
  • Struggle: No current team struggles.
  • Big Win: Wrote and designed a short Contributor Day onboarding card. It was used at Contributor Day at WCEU and onboarding time went down to 1 hour instead of 3 hours.

Meta (WordPress.org Site)

  • Contacted: @tellyworth, @coffee2code
  • Priority: Reducing manual work around the contributor space (theme review, GDPR/privacy, plugin review). ETA for small wins is end of quarter, larger efforts after that.
  • Struggle: Maintaining momentum on tickets. There are also some discussions about updating the ticket management process across teams that use the Meta trac system.
  • Big Win: The new About page launched and has been translated across most locale sites.


  • Contacted: @elibud
  • Priority: Getting Gutenberg in the mobile applications. ETA is late December.
  • Struggle: Consuming the Gutenberg source in the ReactNative app directly. More info can be found here: https://make.wordpress.org/mobile/2018/07/09/next-steps-for-gutenberg-mobile/
  • Big Win: The WordPress mobile applications now fully support right-to-left languages and are compliant with the latest standards for accessibility.


  • Contacted: @ipstenu
  • Priority: Clearing ~8,000 unused plugins from the queues. Likely ETA is September.
  • Struggles: Had to triage a lot of false claims around plugins offering GDPR compliance.
  • Big Win: Released 4.9.6 and updated expectations with plugin authors. Huge thanks to the Core Privacy team for their hard work on this.


  • Contacted: @petya, @ocean90, @nao, @chantalc, @deconf, @casiepa
  • Priority: Keep WordPress releases translated to 100% and then concentrate on the top 100 plugins and themes. ETA is ongoing.
  • Struggle: Getting new PTEs fast enough, and complex tools/systems. Overall, the volume of strings awaiting approval.


  • Contacted: @clorith
  • Priority: Getting ready for the Gutenberg callout (it got pushed last quarter). Needing a better presence on the official support forums, and outreach for that is underway, ETA end of July. 
  • Struggle: Keeping contributors participating post-contributor days/drives. Considering the creation of a dedicated post-contributor day survey to get some insight here.
  • Big Win: The increase in international liaisons joining for weekly meetings, helping bring the wider support community together.

Theme Review


  • Contacted: @valendesigns (but usually @jeffpaul)
  • Priority: Storing PHPCompatibilty results inside the WordPress.org API and building a UI to display those results, an endpoint to request an audit is required for this work to continue.
  • Struggle: Development has dramatically slowed down while team members are on leave or pulled into internal client work.
  • Big Win: Migration to Google Cloud Platform (GCP) from Amazon Web Services (AWS) is complete and the audit servers have all been rewritten in Go. (This allows us to be faster with greater capacity and less cost.)


  • Contacted: @bethsoderberg, @juliek
  • Priority: Lesson plan production. ETA is ongoing.
  • Struggle: The workflow is a little complex, so recruiting and training enough contributors to keep the process moving is a struggle.
  • Big Win: WordCamp Europe’s Contributor Day was very productive. New tools/workflow are in place and two team representatives were there to lead and help.

Interested in updates from the first quarter of this year? You can find those here: https://make.wordpress.org/updates/2018/04/24/quarterly-updates-q1-2018/

Source: WordPress

Bad Behavior 2.2.22

Bad Behavior 2.2.22 has been released. This is a maintenance release and is recommended for all users.


The following changes have been made since 2.2.21:

  • A leftover bit of the screening code which was removed in Bad Behavior 2.2.21 caused a spurious PHP notice. This bit has also been removed.


Download Bad Behavior now.


Just as a reminder, if you use CloudFlare, Incapsula, Amazon Elastic Load Balancer, Azure Load Balancer, Google Cloud Load Balancing, or similar services on your site, you must enable the Reverse Proxy option in Bad Behavior’s settings, or many of your visitors and search engines will be blocked.

The post Bad Behavior 2.2.22 appeared first on Bad Behavior / Bad Behaviour.

Source: Bad Behavior

Dev Chat Summary: July 11, 2018 (4.9.8 Week 2)

This post summarizes the weekly devchat meeting held Wednesday, July 11, 2018 (agenda | Slack archive)

4.9.7 Security and Maintenance Release Feedback

  • WordPress 4.9.7 was released on Thursday,  July 5 2018. This was a Maintenance & Security Release. Details here.
  • All 4.9.7 milestone tickets were pushed to 4.9.8. The last devchat summary and some other posts on Make/Core have been updated to replace “4.9.7” mentions with “4.9.8”

4.9.8 Release Leads

As confirmed last week:

4.9.8 Schedule

  • Beta: July 17, 2018
  • RC: July 24, 2018
  • Final Release: July 31, 2018
  • Bug Scrubs: Monday at 14:00 UTC and Thursday at 21:30 UTC during the cycle.

4.9.8 Development Update

Updates from @pbiron:

Focus Lead and Component Maintainer Updates



The JS team posted notes on their meeting. Topics included:

  • Deprecation Strategy
  • WordPress package to be merged into Gutenberg
  • Merging WordPress JavaScript coding standards in Gutenberg
  • Service Workers scope

General Announcements

Devchat Coordination Reminder

Jeff Paul is on vacation, so @whitneyyadrich, @audrasjb, @joemcgill, and @antpb are handling PM-y devchat duties this month: collecting agenda items, publishing an agenda, running the actual devchat meeting, and publishing a devchat summary.

Next Meeting

The next meeting will take place on Wednesday, July 18, 2018, 20:00: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.

Source: WordPress Development Updates

JavaScript chat summary – July 10th

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Participants: @abdullahramzan, @adamsilverstein, @aduth, @aristath, @atimmer, @gziolo, @herregroen, @hypest, Jorge Costa, @netweb, @omarreiss, @pento, @rheinardkorf, @schlessera, @westonruter, @westonruter

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

wp.hooks namespace argument

There was a lengthy discussion about how we should deal with ACF including a wp.hooks library. The version in Gutenberg includes a namespace argument on addAction not present in the ACF version.

  • @adamsilverstein mentioned that we could drop the namespace argument, but have the function throw a console warning if it isn’t provided.
  • ACF should be updated for 5.0 anyway, so this could be part of it.
  • This ties right into the discussion we had last week about deprecation strategy.
  • ACF is using a library that a lot of plugins are using, which is based on the wp.hooks proposal on the trac ticket. So there might be a good reason to preserve backwards compatibility.

No final conclusion was reached.

Deprecation Strategy

There weren’t a lot of changes since last week’s chat. wp.hooks could be a good test case for the deprecation strategy. This will be discussed on the wp.hooks issue.


WordPress/packages has been merged into Gutenberg 🎉. Updated packages still need to be published and released to npm. The only PR that still need to be merged is the update to Babel 7. The new version of Lerna makes managing the packages easier.

For React Native support a few files need to be refactored. Babel 7 and Jest need to be updated. codecov might need to be relaxed for React native to pass the codecov requirements.

Service Workers

A decision needs to be made on which service workers scopes make sense in a WordPress context. Discussion is happening on this pull request.

@westonruter asks everyone for feedback:

At the moment to me it seems it just makes sense to have two scopes, one for the frontend and one for the wp-admin. Please provide feedback there for anyone who has insights.

Coding Standards

The coding guidelines on camelcase have been merged in Gutenberg. The next step is to add those to the WordPress JavaScript standards. There are still some decisions to make about ES2015 standards, but those are for another meeting. The way these can go into WordPress is by first specifying these for Gutenberg and presenting these to the community.

Source: WordPress Development Updates