The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.
Authentication
A new wp-api/authentication GitHub repository was created last week to facilitate the design & development of a REST API authentication solution for WordPress Core.
We continue to be in the information gathering stage. For all interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday, November 14, 2019, 01:00 PM EST) as a weekly standup to coordinate work.
We also invite you to log issues describing use cases the authentication solution should support.
Registered Block Types REST API
#47620 aims to create REST API routes to discover the list of registered block types. It is based off the Gutenberg Block Type Registration RFC. @spacedmonkey worked on a patch and is in the process of soliciting feedback from the Gutenberg team, Mobile team, and other members of the REST API team.
A particular point of concern @spacedmonkey brought up was the difficulties about handling the asset fields ( editorScript, script, editorStyle and style ). The RFC defines the fields as either absolute URLs or relative paths to the source files. However the WP_Block_Type class defines those fields as asset handles.
Further the asset URL or handle is not sufficient to make the asset functional. The list of dependencies, inline scripts, translations, and localized data are all necessary for the script to work.
The participants discussed whether it would be better to include this additional information inline in the Block Type response, or to develop a separate wp/v2/dependencies API.
@timothyblynjacobs suggested that including this information inline would be simpler. @spacedmonkey pointed out that then we’d be including full data from a separate resource within the block type response. Elsewhere in the REST API that would be handled by creating a separate API and linking to it.
Additionally, @timothyblynjacobs pointed out that just exposing the list of dependencies isn’t sufficient. The client needs access to the entire dependency graph to ensure each dependency’s dependencies are loaded, and that all scripts are loaded in the correct order.
This all points to a dedicated REST API endpoint being a better solution. The team then discussed the potential privacy and security ramifications about retrieving this information about any registered asset.
A developer may include sensitive data in a wp_localize_script or wp_add_inline_script after registering the script with wp_register_script. Currently, this data would only be exposed when the script is enqueued, which may be protected by a current_user_can or $hook-suffix check. If the REST API allowed returning information about an arbitrary asset handle, this data may be exposed.
Additionally, a developer may conditionally registers asset based on a plugin’s settings. By allowing a user to check if a handle is registered via the REST API, it may be possible to determine the setting configuration of a plugin. This may not be desirable for security or privacy related plugins.
@kadamwhite mentioned that historically the REST API has been pretty conservative about what data is exposed. If possible, he’d like to continue along that path. Or theoretically authentication could be required for some pieces of the API since the use case seems to mostly be for editorial interfaces which would require auth anyway. @spacedmonkey also suggested a capability check.
@spacedmonkey and @timothyblynjacobs proposed limiting the assets exposed to ones registered via WP_Block_Type and all WordPress Core assets. Additional assets could be exposed via a registration flag of some kind, like show_in_rest.
Both @aduth and @youknowriad mentioned that this functionality would not just be useful for blocks. As WordPress moves more and more to JS powered interfaces, the ability to lazy load assets will become increasingly important. The problem here could be generalized to “retrieve all the information necessary to properly load a handle”.
@youknowriad opened a ticket, #48654, to continue the discussion on Trac.
5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!
In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:
What should WordPress start doing as a part of the development process?
What should WordPress stop doing as a part of the development process?
What should WordPress continue doing as a part of the development process?
Please share your thoughts in the comments below! Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.
She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.
Here are a few statistics:
12 weeks of development
A release squad with nine focus leads, covering every relevant component that got an update
645 contributors
658 bugfixes
A new default theme, Twenty Twenty
Lots of fun and new friends made
And much, much more!
Before release the squad counted at least 153 user-experience enhancements.
Highlighted Posts
The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.
Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!
Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.
That’s how WordPress gets better and you get to shepherd your best ideas through the process.
@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!
@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”
@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “
@sergey asked “If we have a `javascript` focus, should we add one for CSS as well?
After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.
She asked the folks talking about CSS to follow this process:
Make a proposal on the Core blog
Discuss
Come to a conclusion
Act
Here are the reports from other component maintainers:
@williampatton: “Themes component is looking good. Prepping for next release.”
@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.
@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”
@williampattonstarted with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”
A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!
(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)
@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.
@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.
“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.”
This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Please note that this meeting did not change time for daylight savings, and Weekly REST API component office hours continue to be held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack. 🙂
Authentication
The first half of the meeting discussed the newly-created wp-api/authentication GitHub repository, a follow-up to discussions at WCUS contributor day around rebooting work towards a canonical, core Authentication solution to permit the Mobile team to use the REST API instead of XMLRPC.
Our target for a merge proposal some time next year is to have an use the OAuth 2 handshake flow with dynamic client registration, which issues revocable, long-lived JWT tokens. The repo has no content so far, but we will start work by focusing on UX and the desired user-facing and technical flow rather than diving immediately into code.
@spacedmonkey, @derekherman, and others intend to drive this project over the coming months. If you who is reading this or any colleagues of yours are interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday at 18:00 UTC) as a weekly standup to coordinate work.
Priorities & Goals
Priorities for Next Release
Key tickets highlighted for consideration as part of the next release cycle include, but are not limited to,
If you have a ticket to highlight or propose for the next bugfix or major release, please leave it as a comment below or raise it in #core-restapi. Thank you once more, as well, to everybody who helped drive our API improvements in 5.3!
Documentation
We are behind schedule in updating the REST API handbook to cover the recent changes in WordPress 5.3. @timothyblynjacobs and @kadamwhite will be working to roll these updates out over the coming week. Handbook content is managed at github.com/wp-api/docs.
Open Floor
@timothyblynjacobs raised #44568 and #44886. Because WordPress operations are non-atomic, these race condition issues are not limited to the REST API and were determined to be out-of-scope, so #44886 was closed as wontfix.
Several bugs were raised and have been provisionally milestoned for 5.4, with the option to backport as needed once addressed.
To increase contributor awareness of REST API tickets, we discussed holding periodic component scrub meetings in the main #core channel.
In this newest release of Gutenberg, block content areas and the navigation block continue to be iterated upon. An experimental block pattern API has been added, and themes can now define custom gradient presets!
The navigation block, demonstrating newly improved horizontal block movers.
The block editor provides default gradient presets. Now, a theme can overwrite them and provide its own:
The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.
Because of DST there was a decision to move the meeting one hour later. The async discussion is still open until Monday, November 18th to decide if people, other than those present at he core editor chat want it differently.
WordPress 5.3 was released yesterday
@youknowriad: Big kudos to all the contributors. It’s a huge release for the block editor
@jorgefilipecosta I would like to thank all the people that contributed and made all this improvements and bug fixes possible!!
There is some current effort to iron out issues that may appear.
I finished a big refactor for the legacy widgets, made some improvements on the custom gradient picker, worked on some PR reviews, continue the work around having configurable inner block settings to allow a parent block to absorve the child, and continued the iterations on some PR’s I had open.
For the next week, I’m hoping to merge the simulated media queries mechanism; I want to get involved again in the navigation block work, so I hope to do many reviews there and maybe pick up some tasks, besides that I will continue the buttons block and innerblocks UI work.
For task coordination: I’ve mostly been reviewing nav-related PRs this week and will be away from the 14th to the 24th November. (In case anyone wonders why I’ve gone strangely silent :D)
Embedding Multilingual ability as standard core functionality: seems a bit early for implementation but it’s definitely being considered.
Let’s review more PRs!
Just a note to everyone. Do please also spend a little time going through older PR’s. As there are many just hanging waiting for a comment, a review etc. We’re definitely falling behind in terms of reviews.
The number of open PR’s increasing which in part is a good signal it means the project is getting more interest, but we should try to review these PR’s as soon as possible so new contributors keep the interest in contributing and we get the features/fixes sooner.
Some discussion ensued on what is needed to merge this pull.
Post on make.wordpress.org regarding any code standard changes affected by this pull (and to inform about the change). This will need further feedback from core lead devs, core committers and contributors.
There are some rule removals from the es-lint plugin package, some discussion ensued about how to handle that and are those changes necessary. At a minimum, there seems to be some agreement that the ESLint rules should match the standards.
Tasks:
Check how many of the existing eslint rules could stay unmodified and what can be tweaked to work with Prettier and which need to be disabled. Should align with whatever standards are for the project (including any necessary modifications to those standards)
We should also seek a way so that the eslint plugin can continue to be used without prettier so folks can have the benefit of styling standard checks the same way as of today.
Once the above is done, write a post on make.wordpress.org/core outlining the changes and inviting feedback.
This is a new function that makes it possible to interpolate elements within a translated string and have those rendered as react elements. Currently, doing something like the following can’t be done in react.
In order to have <a> render, you’d need to split up the string, which in turn breaks context for translations. The solution is __experimentalCreateInterpolateElement:
