Javascript Chat Summary: August 6, 2019

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

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

Publishing npm packages

@gziolo announced that we published to npm new versions of all WordPress packages.

@gziolo added that we didn’t publish to npm in the last two months, although we could do it given that Gutenberg release happens every other week.

@gziolo asked for thoughts on how we can improve the process overall, and maybe automate it.

People noticed that the current process involves lots of manual work.

Some options were discussed, @gziolo noted that he does not think we can publish to npm from CI since we require all accounts to use 2FA.

@nerrad suggested we can do an iteration on the automation scripts @youknowriad build andding something like `commander deploy:trunk`.

@jorgefilipecosta noted that an automation tool will face a problem when merging Gutenberg PHP changes to core.

@youknowriad agreed and added that the PHP could never be automated. Both repositories have different PHP setups/requirements (one is a plugin on top of the other). But noted PHP is the small part of the work, and a helper tool could compare versions and say, we have these PHP changes, don’t forget to backport them.

In continuation of the PHP code updates conversation, @omarreiss added that:

Normally I would solve a problem like this by treating the Gutenberg PHP as a dependency of WordPress core. We could install that and keep that up to date by using composer. There is a ticket open for managing external PHP dependencies with the composer, but it’s not moving very fast, see If that were the case, we could register an alternative initializer/autoloader when Gutenberg is active, and we would be done. The only problem is that the PHP in Gutenberg isn’t well isolated. To really solve this problem, the PHP in Gutenberg needs to start behaving like a more clean dependency, and we should centralize its initialization. This would require some refactoring. I wouldn’t mind exploring this approach, but I’d like some blessings on the direction from people like @pento and @jorbin first.

@youknowriad noted that @omarreiss suggestion means re-architecture WordPress to be built using PHP modules (same as we do with JS). @omarreiss agreed and said that was the reason why he does not want to explore further without some openness to the direction.

Help build an automation tool

@gziolo asked if we have someone willing to explore how we can automate as much as possible to make the process on WordPress core side less time-consuming and error-prone?

@dsifford said that he does not want to get distracted from the other work he is currently doing (jsdoc improvements), but we can consider him a fallback in case no one takes up this task.

If this task is something that interests you, and you want to expand knowledge about scripting and automation, please tell us about your interest in the comments.

Gutenberg Examples repository

@gziolo opened the topic by saying that we still maintain a repository with Gutenberg examples (, and asked:

What’s the process like for such repositories with merging changes? I have PR opened, and I have no idea what to do next:

@netweb answered:

What I typically see is another Gutenberg core dev will to a drive-by review, approve and merge. So, nothing official.

The conversation continued and aborded specific subjects related to the PR @gziolo referred.

@gziolo concluded that although this repository isn’t as popular as others, we should still go through review/approve process as it’s useful.

Other subjects

@dsifford asked for reviews on PR – “Add eslint-plugin-jsdoc for better JSDoc linting“.

People talked a little bit about that PR and chat participants provided some feedback.

Meanwhile, after the chat, the PR got a review, was approved and merged.

#core-js, #javascript, #meeting, #summary

This is a summary of the shiny updates…

This is a summary of the shiny updates chat from May 24. (Slack log)

Attendees: @ocean90, @swissspidy, @mapk, @ryelle, @melchoyce, @adamsilverstein, @obenland


  • Open Pull Requests
    • @swissspidy was waiting for feedback and a merge on PR120, which happened right after conclusion of the meeting.
    • @ryelle was waiting for clearance to re-globalize pagenow in order to make more parts of shiny updates testable.
  • Overall status
    We should be at a point where we can write the merge proposal and a patch in the coming week. We have one more week to fix more bugs and get some more user eyes on update-core and themes. @ocean90 mentioned two core tickets that should be fixed before merge, #13071 and #36914 and asked for review and testing there.

Next meeting is therefore on Tuesday May 31, 20:00 UTC.

#4-6, #meeting, #shiny-updates, #upgrade-install

HTTPS discussion meeting this Wednesday

In recent releases of WordPress there have been various improvements made to support for sites running on HTTPS. While support is currently very good, it’s still too easy to end up with mixed content on a site (HTTP content embedded within an HTTPS page), and especially so when migrating an existing site from HTTP to HTTPS.

There will be a discussion meeting in the #core-http Slack channel on Wednesday, January 27, 2016 at 2000 UTC. This is one hour before the regular weekly meeting in #core. I’d like to discuss three topics:

  1. Implementing an (opt-in) method of forcing a site to use HTTPS.
    • What should this cover? (Embedded content, enqueued scripts/styles, links, redirects)
    • How should it be implemented? (eg. filter/constant/automatic)
  2. Defaulting to HTTPS for new installs when it’s available.
    • Only applies when setting up a site over HTTP and it’s available over HTTPS.
    • Need to communicate clearly to the user what this implies, with option to toggle.
  3. Aiding in switching an existing site from HTTP to HTTPS.
    • Migrating existing embedded content.
    • Should this be a feature plugin?

If you’re interested in helping out with any of the above, or with HTTPS improvements in general, join us on Wednesday.

Further reading: the https tag on Core Trac.

#https, #meeting

Shortcodes roadmap — clarifications

As mentioned in the initial shortcodes roadmap post, the main purpose of this roadmap is to find the best way for improving the shortcodes API and moving it forward. Currently it is slow, fragile, and attempts to handle a lot of edge cases. For this, the most important part is:

  • No shortcodes in HTML tags attributes.
  • No HTML in shortcodes attributes.

There are a few things that deserve to be clarified. Simple shortcodes are great. They are easy to understand and be typed directly by the users. Example: [gallery].

Unfortunately many plugins add complex shortcodes with many attributes and often with nested shortcodes. These are a nightmare for the users. They are not intended be typed directly and can be edited by some sort of UI. Using shortcodes to store this type of data in post_content is not a good idea. Since there is a UI for entering and editing, it would be better to use a simple shortcode to “hold the place”, and save all the data in post meta.

Many of these complex shortcodes also include HTML tags in their attributes. To keep that functionality, the second roadmap draft proposed an extended syntax that allows the shortcodes “content” (the text wrapped by [shortcode] and [/shortcode]) to be additionally separated by delimiters. That would allow for shortcode attributes to contain HTML tags that are stored in the shortcode content.

These delimiters are not intended to be typed directly by the users. They are intended for the plugins that have shortcode editing UI and cannot function without storing HTML in shortcode attributes.

At first look this makes the syntax needlessly complex. However after looking at how complex shortcodes are used now, it is relatively the same: these shortcodes cannot be typed directly and are useless without some sort of UI.

There have been questions about line breaks in shortcode content. It is possible to add support for this. However it will benefit only a very small amount of users. Since shortcodes “live” in HTML context, and line breaks are ignored there, typing in the Text editor and switching to the Visual editor will remove all line breaks. Typing in the Visual editor will add paragraph tags. So only users that never use the Visual editor and have to type long, complex shortcodes will see some benefit.

The Shortcode API Roadmap meeting is in #feature-shortcode today at 17z, which is 2015-10-14 1700.

#meeting, #roadmaps, #shortcodes

Shortcode Roadmap Draft Three

This is the third draft of the Shortcode API Roadmap. It describes in broad terms the changes that might take place across versions 4.4 through 4.6. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

This roadmap is based on decisions made at meetings, feedback received on previous posts, and consultation with the core developers.

Our need for a roadmap arose from specific problems in the old code.  There are performance problems in parsing shortcodes, and we need to fix those problems with backward compatibility in mind.  Recent security patches illustrated the problem of not being proactive about security hardening.  Bloat in content filters is another big problem that complicates efforts to correct problems.

Please comment on this new draft.  We will have another meeting Wednesday at 17Z, which is 2015-10-14 1700.

4.4 – New Restriction on Shortcode Names

There is only one item on the 4.4 Milestone. It helps us move toward our goal of security hardening without breaking websites.  Names of registered shortcodes will be slightly restricted by disallowing angle braces.  It should be possible to implement this change immediately with no impact on existing content or plugins.

The < and > characters will be no longer allowed in the $tag parameter of add_shortcode(). Starting in 4.4, attempting to register an invalid shortcode name will result in a helpful error message.

These characters will be forbidden in shortcode names: [ ] < > / &

Also forbidden are the “non-printing characters” including spaces, tabs, new lines, and other control sequences.

Continue reading

#meeting, #roadmaps, #shortcodes

Shortcode Roadmap Draft Two

This is the second draft of the Shortcode API Roadmap. It describes in broad terms the changes that might take place across versions 4.4 through 4.7. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

This roadmap is based on decisions made at the meeting in #feature-shortcode, as well as feedback on previous posts, and consultation with the core developers.

Our need for a roadmap arose from specific problems in the old code.  There are performance problems in parsing shortcodes, and we need to fix those problems with backward compatibility in mind.  Recent security patches illustrated the problem of not being proactive about security hardening.  Bloat in content filters is another big problem in itself.

Please comment on this new draft.  We will have another meeting next Wednesday at 17Z, which is 2015-10-07 1700. Trac tickets that were nominated for closure at the last meeting will be closed today, with references to this draft.

4.4 – Introduce Multiple Enclosures

The two items on the 4.4 Milestone help us move toward our goals of security hardening without breaking websites.  A new delimiter in the shortcode syntax will enable plugin authors and users to always place their HTML between the shortage tags rather than inside of them.  At the same time, the names of registered shortcodes will be slightly restricted by disallowing angle braces in shortcode names.  It should be possible to implement both of these changes immediately with no impact on existing content or plugins.

New Delimiter

A new addition to the shortcode syntax along with documentation of how it works will be created in the 4.4 development cycle.  Its purpose is to allow more than one HTML enclosure in a single shortcode. Use of this new delimiter is optional or as needed.

Enclosure Delimiter:  [parent:attr=]

Usage:  [shortcode] Content HTML [shortcode:name=] Attribute HTML [/shortcode]

Example:  [photo link_to="twentysixteen/"] Here is <b>my</b> caption. [photo:media=] <img src="00.twentysixteen-260x300.png" width="260" height="300" /> [/photo]

    delimiter   =  begin code-name middle attr-name end
    begin       =  "["
    code-name   =  1*( ALPHA / DIGIT / unreserved / %x80-FD )
    middle      =  ":"
    attr-name   =  *( ALPHA / DIGIT / "-" / "_" )
    end         =  "=]"
    unreserved  =  "!" / "#" / "$" / "%" / "(" / ")" / "*" /
                   "+" / "," / "-" / "." / ";" / "?" / "@" / 
                   "^" / "_" / "{" / "|" / "}" / "~"

In the examples above, the “name” part of the new delimiter works the same way as an attribute name. The main difference when using this new style of attribute (the enclosure) is improved support for HTML inside the value text. One basic reason why this works better is because our HTML filters do not need to understand how to look in the middle of individual shortcode tags. All of the HTML is located between shortcode tags, making the shortcode and HTML codes easy to process separately.

Continue reading

#meeting, #roadmaps, #shortcodes

Taxonomy meeting summary – 2015/09/03

Present: @boonebgorges, @swissspidy, @masonjames, @drewapicture, @georgestephanis, @khromov, @srwells, @michaeltieso, @dpegasusm, @kraft, @mrahmadawais, @samuelsidler, @leatherface_416, @jblz, @tyxla, @jeroenvanwissen, @lindsaymac, @eric, @jbrinley, @brashrebel, @pdufour, @joehoyle, @timothybjacobs, @ryanduff, @krogsgard, @aaroncampbell, @rahe


  • Had a general discussion about term meta: who’s used plugins for it, who’s used workarounds, various use cases. We talked a bit about some arguments against term meta: that it will not perform well at scale, that it encourages poor data modeling – but decided that they could be set aside for the most part.
  • Outlined the interpretation, including database table name and schema, function names, and other API additions to support term meta. @boonebgorges will work up a RFC for make/core for feedback.
  • Talked about various ways in which existing term meta libraries might conflict with the core implementation: duplicated function names, duplicate table names, incompatible table schemas, etc. @boonebgorges is assembling a list of plugins in the repo that may conflict with the core implementation. Once the outline of the core implementation is pretty much settled, @aaroncampbell, @krogsgard, @masonjames, and @boonebgorges (and anyone else who is interested) are going to collaborate on reviewing these plugins to see which ones will conflict in serious ways (via a Google Doc, which @boone will share once we’re ready to go). This will help us gauge the extent of potential problems, and get a sense of what outreach will look like.
  • We talked a little about combining the wp_terms and wp_term_taxonomy database tables #30262. We outlined some backward compatibility concerns, and strategies for minimizing conflicts. Put out a general call for thoughts and initial patches on the ticket, though we probably won’t move forward with schema changes for at least one more release cycle.
  • Had a very brief discussion about WP_Term #14162. Initial implementation – probably doable for 4.4 – will be simple, and will focus on strict typing for term data as well as cache invalidation. Future releases may see more functionality moved to the class.

#4-4, #chats, #meeting, #summary, #taxonomy

Shortcode Roadmap Extended Discussion

We saw a great amount of feedback on the first draft of the Shortcode API Roadmap.  The resounding concensus was that the shortcode syntax we already know and love should not be replaced.

Now we need to bring that enthusiasm and more feedback to the first official meeting to help create a second draft of the roadmap.

On Wednesday at 17Z, which is 9 Sep 2015 17:00.

It is scheduled in the #feature-shortcode channel.

In case you can’t make it to the meeting, here are some of the items up for discussion.

Parser Problems

The biggest issue with keeping the BBCode style syntax is that we don’t have a scalable way to make these shortcodes work in PCRE.  The current pattern searches for all registered shortcodes by name, because searching for matching pairs of braces leads to backtrack limitations and segfaults.  If someone has an idea or knows a good library, now is the time to tell us!  With that said, we are also bringing some new proposals of our own.  One theoretical solution should make it possible to preview the first word of each shortcode tag so that the full search pattern then only includes the names of shortcodes already found in the input, rather than the names of all registered shortcodes.  This is the best idea so far and could be easy to implement.

HTML vs. Shortcode Syntax

We still want to expand the shortcode syntax to allow multiple enclosures.  So which new tags would work best internally and still look nice for users?  We are now thinking something more like this:

[shortcode] HTML [=part2=] HTML [/shortcode]

Let’s also have a brief discussion about preparing for the eventual removal of HTML-in-shortcodes and shortcodes-in-HTML combinations. As we saw in 4.2.3, it is better to plan for this rather than allowing it to become an urgent surprise update.

Version Issues and Breaking Things

We still need to plan out a change of filter priorities so that shortcodes will be processed first, before paragraphs and curly quotes. How much impact will this have on plugins now that we will be changing the way existing shortcodes work instead of adding a whole new system? Is it adequate to offer paragraphs and curly quotes as an opt-in only feature?

Will we need weekly meetings after this first one?

Are there other tickets or features, such as nested shortcodes, that need to be roadmapped?

#meeting, #roadmaps, #shortcodes

Dev Chat Summary, June 10

Agenda, Slack log.

Menu Customizer Status Update (#)
The a11y review did not unveil any blockers, although it wasn’t done on the feature branch the team is currently working on. Introduction of a blocker there was deemed unlikely however. A new plugin version can’t be released since it’s now dependent on some core patches being applied.

For the rest of the requirements: The biggest blockers are almost complete, Customizer setting re-architecture and sub-menu drag & drop. The settings re-architecture has been integrated into JS for the nav menu items, allowing nav menus to be edited, added, removed all with 100% previewability and not making any changes to the DB. Once Save & Publish is done, any newly created nav menu items get inserted at that time. Same goes for nav menu deletion. The submenu drag & drop has been merged into the same branch and it is all working together now.

The biggest outstanding pieces are:

  • adding back the ability to add/remove entire menus
  • updating keyboard-accessible reordering to work with new menu settings
  • more unit testing for PHP, and write tests for JS

Estimated time of completion is June 11, which leaves 5 – 6 days to merge.

Admin UI (#)
Even more prep work has gone into list tables, now working on the responsive part on #32395. They have gotten some feedback so far, would love more even on the rough cuts. Helen will be at wordcamp philly’s contributor day this weekend, looking to knock through a bunch of the low hanging fruit on the screen sweep spreadsheet, and find takers for some make-flow tickets (#29906 in particular). She has some catch up to do with other contributors on visual regression testing and media-new, which will happen at tomorrow’s meeting.

Network Admin UI (#)

Objectives from last week:

  • #32434 is in. Jeremy is still poking at #22383 and #32503 with a target of this evening.
  • They had no additional iterations on WP_Network and WP_Network_Query, but @jjj is working on having something this week.
  • Did not yet generate discussion around HTTPS. Moving this objective along to this week.
  • They made quite a bit of progress with flows. @kraft added Nexus and @earnjam has iPad screencaptures he will be publishing shortly. Their next push is to start creating tickets. Jeremy wrote a post to try and drum up support – – and they had a handful of people hop in. Pretty optimistic that they’ll start making progress here, especially with a couple contributor days this weekend.

Objectives for this week:

  • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
  • Iterations on WP_Site and WP_Network. Discussion around iterations.
  • #22383 and #32503 committed.
  • Write post, generate discussion around HTTPS in multisite.

Better Passwords (#)
Mark turned the plugin into a patch for the new UI. After a cleanup, that can land, and we can iterate a bit, as well as tackle the new user password flow, which is different. The expiration of reset links (#32429) needs testing (human and unit), before that lands. And the “notify users of password and email changes” patch (#32430) needs a review on the hooks in it. I’m not sure we’re passing the right things along. Like, email instead of the whole user array.

Favicons (Site Icon) (#)
There’s been a status update on make/core. It’s looking like #29211 would be a better approach to a reusable control with image cropping functionality. So John is wondering whether we should aim for 29211 for 4.3 and site icon for 4.4. On the topic of using the Customizer or not: much of the image cropping control for the header image is also used on the old header image screen (it’s mostly media library and ajax functionality), so it’s not necessarily tied to being a customizer control.
Let’s meet today June 11 2015, 20:00 UTC to discuss what a good approach could look like.

Next chat will be on June 17 2015, 20:00 UTC

#4-3, #meeting

Dev Chat Summary, June 3

Agenda, Slack log.

Menu Customizer Merge Proposal (#)
@westonruter, @celloexpressions
We went through the feature plugin checklist and discussed if the plugin was fit for core. It was approved for merge, pending the following conditions:

Items that should be done before merge:

  • Complete a11y audit.
  • Address possible blockers.
  • Merge php tests.
  • Add JS tests.

Then with/after merge:

  • Killswitch for plugin.
  • An outline for a fieldguide post.

Better Passwords (#)
New password UI on Profile screen, via GH plugin. Generates and shows by default. Lets the user hide, or click into the field and type (in show/hide modes). Also, the strength meter has been more closely integrated. The color wraps around the field, and it is integrated as one “unit” instead of being this button-like thing that floats below it. Mark would like to get the current state turned into a patch and merged, as he thinks it’s a fine inflection point, even if the next steps aren’t ready in time.

Admin UI (#)
Got a lot of a11y fixes in play for list tables. A fair number of small/low-hanging fruit issues being noted, which aren’t crucial to hit before beta, so they’ll keep focusing on the bigger items for now. They also started to sync up with #core-flow issues and getting those into the patch and review queue.

Network Admin UI (#)
Last week’s objectives and progress:

  • Wrap work on the edit site flow and MS sites list table and then take a look at the add site flow and validation in `update_blog_details()`. We made progress on the edit site flow and are nearing commit readiness for a few patches.
  • Continued progress on WP_Network, WP_Site, WP_Network_Query, and WP_Site_Query. We had quite a bit of discussion on the WP_Network ticket and in Slack. Not much ticket progress, but we’re doing good at continuing to pay attention.
  • More thoughts on tracking scheme in wp_blogs for sites. We discussed this in the meeting yesterday and need to do some more research on impact. There’s some info in the recap, but we’ll also have a call for info/thoughts soon.
  • More flows and network admin UI tickets from those flows. We have iPhone 5s flows from @ubernaut. We need to do more creating of tickets and generating of additional flows.

Objectives for next week:

  • Have all 3 tickets related to the edit site flow closed and committed.
  • Additional iterations on WP_Network and WP_Network_Query. Please watch this.
  • Generate discussion around tracking site scheme. @jeremyfelt will gather a list of HTTPS related tickets and share.
  • Nexus (@kraft) and iPad (@earnjam) flows. Tickets created for bugs found in existing flows. Volunteers needed!

And the recap has all the juicy details:

Favicons (#)
Site Icon progress has been slow due to him being too busy, but he has a working implementation now which he will put up in a repo on GitHub tomorrow, then he’ll see about liaising with contributors to get feedback, and basically go from there.

Next chat will be on June 10 2015, 20:00 UTC

#4-3, #meeting