Make WordPress Core

Keyboard Shortcuts | Hide comment threads

Developer Hours now scheduled, first event Feb 8th, 2022

A few months back, I posted a proposal for four trial events called Developer Hours. Although, it received great comments and a few people reached out to me on Slack, it wasn’t until now that everything comes together to make it actually happen. Thank you all for your patience!

Meet the fantastic team of developers who will take turns for the four events coming up.

We have two events each month for February and March on Tuesdays every other week at 11 am ET / 16:00 UTC.

The first event will take place February 8th, 2022. Details will be posted on Meetup.com.

Join us for the first of hopefully many events. And bring your questions, code samples, demos, and ideas about blocks, themes, block themes or the block editor, to run by our expert panelist.


@karmatosed created this template for the social graphics to announce the events.
@ndiego created a block pattern, so we can update information for the next events.

Huge “Thank You” to the +training team for giving this event series a home on the WordPress Social Learning space.

Also Thank you to @marybaum for reviewing this post.

This sounds great, though will unlikely be able to make this timing so I hope its recorded for on-demand viewing?!

@jeffpaul Thank you! 🎉
We will record the session, but we will also double-check with participants, before sharing projects code publicly. I certainly will post a learned lessons and resources. I am not quite sure yet, where, though 🤔

Dev chat summary, January 26, 2022

@marybaum and @webcommsat led the meeting on this agenda.

The overall focus: celebrating WordPress 5.9, “Josephine,” which landed Tuesday, January 25, after months of hard work by more than 600 contributors and a release squad with @hellofromtonya at the helm.

Announcements

WordPress 5.9, ”Josephine,” is here!

Ahead of the 24-hour code freeze for 5.9, the squad released WordPress 5.9 RC4 on Monday, January 24, 2022. The freeze took effect immediately afterward.

Read the latest developer notes.

Blog posts of note

What’s new in Gutenberg 12.4 (January 19, 2022)

A Week in Core (January 24, 2022)

Join the discussion on 2022 release planning (December 27, 2021 post by @chanthaboune). New document coming

New additions to the agenda:

Preliminary Roadmap 6.0 (January 26, 2022)

Let’s talk about WordPress 6.0 post and video hosted by @annezazu – Hallway Hangout in #fse-outreach-experiment (December 21, 2021)

After celebrations and discussion on the above, @desrosj added two more posts, both from @chanthaboune, to the list.

Our Three Big Ideas for 2022!

Big Picture Goals 2022

As @desrosj pointed out, these are really important for the year ahead. Please have a look and let @chanthaboune know if you have thoughts or questions.

An update

Well after the chat—Thursday, in fact—@chanthaboune published Proposal: 2022 Major Release Timing. Take a look and add your thoughts there!

Major releases

@hellofromtonya took the mic (metaphorically speaking) to congratulate everyone on the historic release and shared that after ten million downloads in the first 24 hours—ten million!—Trac showed a grand total of 17 issues, none of which raised any major issues or concerns. (Ed. note: If you speak the language of nines, where 99.9% uptime or other metric = three nines, the first 24 hours of Josephine showed nearly six nines of flawless performance.)

Looking ahead, Tonya addressed the timing of the first minor. There are patches and pull requests ready for 5.9.1 ready now, and the current thinking is for a quick release as soon as a couple of weeks from now.

She also said she was working on a 5.9 retrospective, planning to publish on Thursday, and it is out now. Please add your thoughts on the process in the comments!

Open Floor

WPDB got major love in Open Floor.

First, @craigfrancis shared ticket #52506, which updates `wpdp::prepare()` to escape identifiers safely. There were emoji equivalents to a bevy of oohs and ahs from the Core committers in the group, and @audrasjb marked the ticket Early for 6.0.

Second, @johnjamesjacoby proposed ticket #54877 to fix the occasional exception that a WPDP/MySQLi connection can throw. The group was equally appreciative of that.

With seven minutes to spare, the chat ended with several members running off in search of ice cream.

Want more details? Read the whole chat.

P.S. Want to start contributing to WordPress, and to Core in particular? Come to dev chat and volunteer to craft these summary posts! We refer to the activity as taking notes, but the whole chat is in text, so there aren’t really any notes to take. And how cool is it to be able to say you’re an author on make.wordpress.org? Pretty cool, I say. — MB

#5-9, #dev-chat, #summary, #week-in-core

Proposal: 2022 Major Release Timing

After our initial discussion about potential release timing for the year, I would like to suggest two additional 2022 releases:

  • 6.0 – Late May
  • 6.1 – Mid October

I believe that the relationship between WP5.9 and WP6.0 will be similar to the relationship between WP5.0 and WP5.1 in that there will be copious user feedback to process so that we can extend, refine, and in some cases even rework the user experience with the vast new feature set introduced in 5.9. By aiming to release WP6.0 in late May, we can let WP5.9 breathe a little, work through the rest of the Phase 2 roadmap, and prioritize WordPress-wide needs as we encounter them.

Given the complexity of our last pair of similar releases, I would love to see some Five for the Future sponsored project manager-ish people* join @jeffpaul and @priethor in addition to our usual release squad. If you’re interested in participating in a squad and want to know more, you can ping @chanthaboune, @jeffpaul, @priethor or any former release squad member you know!

*So as not to startle anyone or overpromise anything—I’m not suggesting that we need a bunch of people to show up and boss around all of our brave and generous contributors. I’m suggesting that a 19-year-old project can no longer be fully tracked by a person or two and the people who are tracking all of our moving parts could use some support.

#planning

I think that will be a lot less stressful for developers who have to update themes/plugins. I like that and appreciate it greatly!

(I’d put my hat in for ‘not on May 27th, because it’s WP/my birthday’ but mostly as am amusing comment and not anything serious 😉 )

I know it’s never happened before, but based on the described intent, why isn’t the May release 5.10?

I was just talking about that yesterday! I think it just comes down to tradition.

It probably is a decade too late to ask this, but is there a reason that version numbers always go x.8, x.9. y.0, y.1 instead of x.8, x.9, x.10 (or x.7, y.0)? In general, I’m curious as to why major version number bumps aren’t reserved for major changes. FSE could easily have been a good excuse to skip 5.9 and go straight to 6.0.

Partly it’s a marketing thing, in that you could have made a bigger deal of a new major release. Partly it’s a managerial-perception thing, in that I’ve already got people in suits and ties asking me how we’re preparing for the major new 6.0 release that’s coming soon, when we know that the delta from 5.9 to 6.0 probably won’t be that dramatic.

I always wondered why not to go to decimals as today there aren’t any difference between a major to another.
I mean 5.0 it was really a major because of gutenberg and this make a difference but between 5.9 and 6.0 what is the real difference?

Yea, the WordPress project doesn’t use semantic versioning, which has been true as long as we’ve been around. That decision was made long before my arrival, so I can’t really give you any insight into why!

WordPress 5.9 ‘Joséphine’ Retrospective

Having fully celebrated the release of 5.9, but before turning focus to 6.0, it would be helpful to this and future squads if all those involved in contributing to 5.9 could take a few moments to share your thoughts about the release process.

Taking the pulse in the form of a retrospective helps to:

  • Discover the things the WordPress core team finds valuable to keep doing in future releases because they were a positive experience and moved the project forward.
  • Help identify areas that were not helpful in fulfilling release goals or were not positive for people participating.

All feedback is valuable to help to continuously improve the release process.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

~ Norm Kerth, Project Retrospectives: A Handbook for Team Review

Anyone is welcome to participate in this retro. Please take a few moments to fill in the form or leave public feedback in the comments below.  The form will be open until February 14, 2022.

Please note, the form is not anonymous as it asks for your email address. Your email will only be used for follow-up questions and will not be used for any marketing or other purposes.

Thank you everyone for your contribution to this release! Thanks in advance for taking the time to help make future releases even better!


Props to @audrasjb for peer review.

#5-9, #retrospective

The release delay is one thing I’ve wondered about. Not the delay itself, but an “extra” process was put in place that would seem to mitigate this sort of thing. That being the “Go/No-Go” meeting(http://wayback.fauppsala.se:80/wayback/20220130162906/https://make.wordpress.org/core/2021/10/15/wordpress-5-9-feature-go-no-go-october-14-2021/). This was only a few weeks prior to the delay.

Given that the release was delayed by a month, what part of the Go/No-Go process needs to be improved? More Core stakeholders involved?

My thoughts on 5.9 is that also if WordPress get to freeze for new stuff Gutenberg it isn’t and to me lead to delay of this release. With all the burn-out for this change of the last minute for a pull request in Gutenberg.
An example of people tired of this way to manage the development process: http://wayback.fauppsala.se:80/wayback/20220130162906/https://twitter.com/Mte90Net/status/1487084641517514755

I like a more long release, as in Open Source usually stuff is released when it is ready and not by dates.
From the other side I see that in the last years is always more difficult to get address bug tickets on WP (not gutenberg ones) and to me, they should get priority as it is clear that Gutenberg follows a different management that doesn’t work with the WP ones.

PS: I was thinking to abandon to contribute to WP for patches a lot of times, but I’m still doing because there are old patches still waiting for a review, and sometimes my customers had issues, so I work on a patch to fix it. But if I could choose, I will abandon totally to contribute to WP core as it is not worth it.

Preliminary Roadmap for 6.0 (Gutenberg Phase 2)

Yesterday, WordPress 5.9 Joséphine was released with the help of hundreds of contributors and achieving a big milestone for WordPress. It’s now time to start thinking about next steps and the general scope for 6.0. As before, this is meant to be a high level overview of the different areas of focus, not an exhaustive list.

The overall aim is to consolidate and expand the set of customization tools introduced in 5.9 for creating themes with blocks, with a special focus towards usability and refinement. This new release could be considered a conceptual wrap for Gutenberg: Phase 2. This doesn’t mean the customization phase would be concluded with it, but that its main features would have been established.

Editor

The introduction of the site editor marked a big milestone but also just a first step in the journey. There are various limitations that need to be lifted and features that didn’t make the cut that need to be revisited. We are also going to be learning a tremendous amount from users now that the initial work is out in the world to be experienced.

  • Refine the information architecture and template browsing experience. There’s work to be done to better organize the experience of interacting with the site editor, global styles, templates, and navigation as a whole. (36667)
  • Improve template creation (aiming at never showing disconcerting empty states) and allow the easy creation of more specific templates (i.e: category-$slug). The selection of new templates is artificially constrained right now in the interface. Opening that up should better express the power of the site editor as a web creation tool. (37407)
  • Expose site structure as “navigation” outside the navigation block. This is an important aspect to not limit site navigation editing exclusively to the site canvas, which for many reasons can be initially hidden from view. (36667)
  • Introduce browse mode to be able to conveniently follow links to different parts of the site. Conversely, the template editor that spawns when editing posts or pages also needs to establish better flows with the site editor. There’s a larger theme of connecting pages and templates to be explored. (23328)
  • Embrace style alternates driven by json variations. This was teased in various videos around the new default theme and should be fully unveiled and presented in 6.0. One of the parallel goals is to create a few distinct variations of TT2 made just with styles. (35619)
  • Improve post settings design and organization. The sidebar has gone without many updates for a while and could use improvements in clarity and design.
  • Complete the scope of global styles. Introduce easy export & import; support for revisions; etc. (27941
  • Remove coupling of templates to specific themes. This is crucial for properly embracing the power of block templates. Switching themes should not cause the disappearance of your modified templates. This is also fundamental for offering more granular combinations instead of complete theme swaps, the ability to add new set of templates (relevant for plugins that introduce new templates), or changing individual parts of a site. (See also.)
  • Explore more advanced drafting and scheduling for the site editor. Some of this work is meant to happen more in depth during Phase 3, which will include more focus on editorial flows, but there’s still some paving steps to implement. (29575, 29388, 31456)
  • There should also be some room for some minor back to basics around the core writing experience and further improvements to performance and usability. Areas to keep an eye on are the reliability of undo/redo, keyboard interactions, multi-selection, etc.

Patterns

It’s also time to expand the usability of patterns as a main ingredient when it comes to building pages and sites, now that most of the infrastructure has been established.

  • Prioritize pattern insertion on template building. This is a proposal to make patterns more central to the experience of creating theme templates and pages. (31153)
  • Simplify registration of patterns for themes. This might take the shape of a patterns folder with file headers that are automatically registered. All in all, it should be super easy for themes to provide a collection of patterns or to specify starter content as patterns. (36751)
  • Introduce page patterns for page creation. This has been on the horizon for a while and we should have enough building blocks to tackle it properly. It’s also an occasion to improve upon and align with the new “explore” modal that connects with the patterns directory.
  • Use patterns as possible transforms for offering “layout” options. Inserting new patterns is just a start, but often you want to change existing content or shapes into new ones. Patterns have some of those mechanisms but they need to be better presented and embraced. (27575)

Blocks

  • Finalize scope of navigation block and its overlay rendering. The navigation block introduced in 5.9 contains a whole world of customization and opportunities that needs to continue to expand and improve. In addition to the block itself, several flows need to be refined around transporting and initializing block menu data.
  • Introduce various new blocks to power the display of comments on themes. (34994, 38107)
  • Allow the featured image to be an attribute of other blocks (like Cover, Media & Text, etc) to expand what designs can be achieved.
  • Allow Quotes and Lists to have child blocks. Some of the current limitations of the writing experience arise from this constraint. (25892)
  • Improve the Table block. There’s a good design direction to finally implement. (32400)
  • Explore the viability of inline tokens. This has come up repeatedly in the context of rendering dynamic strings (such as current date) in rich text blocks.
  • Migrate default block styles into proper style attributes. Continue the work put into global styles by making all systems understand each other.
  • Pick up the work done for a Table of Contents block.

Design Tools (33447)

A lot of progress was made in 5.9 around consolidating the set of design tools and introducing new ones to address major gaps in the experience and providing block authors with simpler ways to register them. For 6.0 there’d be a concerted effort around tightening consistency, introducing more responsive capabilities, and expanding the Supports & Elements API. Another important goal is to continue to make it easier for third-party blocks to adopt these tools.

  • Layout:
    • Address confusions and shortcomings of layout features (including mindbenders like “inherit layout”). (28356)
    • Explore more convenient direct manipulation for height and width (alignment distribution) of blocks.
    • Incorporate more definitive responsive handling (min/max containers) into the current flex-based tools. (34641)
  • Typography:
    • Introduce responsive fonts with good defaults. (33543)
    • Add a Web Fonts API connected with global styles. (37140)
    • Explore paragraphs with indents and justification with hyphenation as global styles settings.
  • Elements:
    • Introduce support for customizing block Captions.
    • Investigate hover / focus effects and related problems.

Gradual Adoption

Full block themes are at the avant-garde of the WordPress evolution, but work continues to happen to improve how all themes can interact with blocks and make use of the new tools gradually and at their own pace.

  • Continue to adopt theme.json configuration for non-block themes as it aims to simplify and consolidate support for block properties and their capabilities.
  • With the “focused template part” editor established there are new opportunities for non-block themes to start incorporating specific areas for blocks using the site editor interface in a more gradual way, when ready to do so. (37943)
  • Utilize what we have implemented for the navigation block and site structure as the interface to eventually replace the navigation screen.
  • Explore the flows for creating some dynamic templates with blocks (for example, just the archive), similar to the custom page templates support in classic themes.

Please, help define the work to be done by joining the conversations listed in the issues above or giving feedback!

#6-0, #gutenberg

Are there any plans to improve the available settings for the query loop block, for example allowing to exclude categories, tags, authors; selecting a single (or multiple) post(s) based on ID/title? There are so many possible parameters for the WP_Query function which the query loop block can‘t handle yet. I believe this would improve the adaption of FSE if there were more settings available.

Hi! I don’t know if there is a plan, but in this Github link there are a few improvements already done on the Loop Block of the Gutenberg plugin.

The first ones are adding custom taxonomies filtering and multiple authors support, for example, so I guess those updates will be in future releases.

If you are involved there, could you add wp_query_random_post as feature request?

Yes! An updated project tracking issue for the query loop should be ready soon.

So glad to hear that. Without proper tax queries and meta queries, it’s really lacking vs PHP templates.

Yes, I would interested in allowing developers to easily extend the query loop block where needed. #38163

@matveb I would love to see an audit of all core block controls for 6.0 and I am personally happy to work on this. For example, dimension and color support is inconsistent across blocks and some block simply haven’t been updated with newer supports. If this is something worth considering, I will put together a proposal on GitHub.

If I’m not mistaken, @karmatosed started working on a similar audit. I would love to see this effort consolidated in GitHub to have a better overview and tracking as we add more block supports and design tools. It would greatly help us decide what controls make sense to be added to which blocks.

Hello! I did and I got it to a point where shared with docs team and in process of starting to see where that goes from there. I had made some issues from it, but more need making.

I would love to see how we could collaborate together on things like this and even automate because the path I was taking was much more longer because of hand curating. Let’s plan together @ndiego. Thanks for connecting us @priethor.

Indeed, that’d be a part of the work. We should ensure we are consolidating on what makes the most sense, though. That’s why a lot of work was put into more flexibility of design tool panels, so that a paragraph doesn’t become overwhelming with options.

+1 it’s easy to think everything needs all the things, however sometimes it only needs those rarely, it also might need to be combined with other things more, so those things should have them. It’s a balance.

There are plans outside gutenberg? this post is talking about 6.0 for gutenberg or just plans for wordpress in 6.0?

Since the main focus of the WordPress project right now are the 4 phases of Gutenberg, the roadmap would overlap almost entirely. There’s some other ongoing work in other parts of the projects that is still prioritized by component maintainers. Those are generally on trac and would be reflected once a squad is arranged for the 6.0 release.

Coming from #docs team and asking for some love for this teenager: http://wayback.fauppsala.se:80/wayback/20220130162906/https://core.trac.wordpress.org/ticket/4328

We need it for being able to redirect CPTs that WordPress documentation lives on. We have big plans in re-structuring docs but not being able to redirect it properly is a blocker for a long time.

For more info see: http://wayback.fauppsala.se:80/wayback/20220130162906/https://meta.trac.wordpress.org/ticket/5519

I know it’s not attractive but we really need it. Thank you ❤️

With the changes to the Quote Block, it might be good to look at #34454 too.

Are there any plans to update the roadmap or publish a new release calendar for 2022 and 2023 like done previously.

@chanthaboune

Looking forward to all of this, but the green in that button vibrates so much it’s about to trigger a migraine for me.

I would really really love to see Custom CSS come to Global Styles in 6.0, as per this ticket: #30142. This aspect of the Customizer was heavily used by many people, and opens up the ability to easily add some customization to block themes in a powerful and low-code way. I personally do not have the experience and know-how (yet) to make this happen, but I would really really love to support the work on this anyway I can.

Good thought! We had an exploration for the group block that could be repurposed in 25413.

As the focus for WP shifts to blocks and patterns, is there any plans to remove support for classic editor?

Just an idea about the menu “Appearance > Editor beta”:

Simply “Editor” is plain confusing.

It used to be called “Site Editor”, and even in this post Matias uses that term. I can understand that Site Editor is not the name of the menu as it’s about templates and global styles too.

How about “Theme Editor”?

Everything you do in there influences some aspect of a theme, doesn’t it?

I would really love to see an option in the settings to turn off updates, without having to use a plugin. Core, themes, plugins.

IMO the Layout part isn’t getting the attention it deserves. Site editor is good and all but you can’t really use it properly if there is no responsive settings for the columns/groups. I know there is an ongoing progress with the Flex block but I’m afraid it’s going to turn into the new Row block where you either have to pick vertical or horizontal but no proper wrapping based on child size.

What about the IMPORT TOOL? when will that be updated? humanmade or 10up did a 2.0 that is far better when will that be adopted?

No mention of the navigation editor. It was bumped from 5.9 but I thought we were working on it in 6.0?

Proposed improvements to the Core Editor chat agenda and format

This post was coauthored with (some of) the facilitators of the Core Editor chat – @zieladam, @annezazu, @bph, @fabiankaegy, @paaljoachim.

The Core Editor chats are a useful opportunity for contributors to gather, stay updated and share ideas on how to improve the block editor.

Recently, the meeting facilitators (named above) have been discussing making some changes to the format of the chat with the goal of reducing the quantity of status updates in favour of more informal discussion and collaboration. This will involve removing some sections entirely and reducing others in order to make best use of the available meeting time.

To allow for feedback, we are proposing that these changes come into effect as of the Core Editor on 2nd February 2022.

Why are these changes needed?

Regularly chat attendees will know that the most valuable Core Editor chats are those which contain good dialogue and discussion between contributors.

This is particularly true when Gutenberg Core team members are in attendance, as they are able to provide a unique level of insight and expertise based on their understanding of the foundation of the editor itself.

In the past, such discussions have proven to be very useful for contributors seeking help with technical questions and/or to those submitting new proposals for consideration by the community.

As facilitators, we have noticed that this type of dialogue occurs most frequently during the “Open Floor” section of the meeting where attendees are encouraged to submit questions for discussion by those present.

We want to do our best to encourage and facilitate such opportunities on a more regular basis.

What will change?

As a result of these conclusions, we are proposing the following high level changes to the Core Editor chat format:

  • General status updates to be reduced to a minimum.
  • Key project updates to become “async”.
  • An extension of the current Open Floor section.

Let’s visit these in a little more detail.

General status updates to be kept to a minimum

The facilitator will endeavour to cover only the most critical status updates. Currently these are typically:

  • latest Gutenberg release
  • current WordPress release cycle news.

The length of these segments will be considerably reduced in favour of signposting towards external information to be consumed by attendees at their own leisure.

Any important announcements can and should still be made (e.g. release cut off dates .etc).

Key project updates to become async

WordPress contributors are inherently distributed. Therefore, instead of requesting synchronous updates on key Gutenberg projects, contributors will instead be strongly encouraged to provide these status updates async via Github.

The meeting facilitator will then signpost attendees to these updates for consumption at their leisure thereby freeing up a considerable portion of the allotted meeting time.

Many of the key Gutenberg projects already sustain a regular cadence of updates on their tracking issues and we therefore hope that it will be possible for Core contributors to keep their respective projects updated.

Extension of the Open Floor section

As outlined above, we intend to dedicate the majority of the meeting time to discussion and collaboration. In practice this means that we intend to extend the Open Floor section to encompass more of the allotted meeting time.

This section will retain the existing format; namely:

  • facilitator will determine ordering of discussions.
  • attendees can provide topics in advance via the Core Editor agenda comments.
  • attendees can suggest additional topics in real time during the meeting.

This will remain a moderated session with the facilitator deciding when it is appropriate to move between topics to ensure a varied discussion.

Let us know what you think

We as facilitators look forward to your feedback on the proposal above and we hope you will agree these changes will have a positive impact on the Core Editor chat.

If you have any feedback please leave it as a comment or feel free to raise it during the Core Editor chat on Wednesday 26th Jan 2022 (note that meeting will retain the current format).


Thanks to @audrasjb and @priethor for reviewing this post.

#core-editor

Hi there!

Thanks for proposing these changes. I think the proposed changes make sense.

I value iterations a lot even when it comes to process. I’m all for trying new things, learn and adapt. (even if lately, I’ve been unable to attend the chats more often because of some conflicts in timing. but I’m sure we’ll all learn from it).

One thing I’m missing personally in this new format is the lack of a dedicated time to recognize and encourage new contributors specially. I know the current approach didn’t scale properly (task coordination), but maybe we can think of something else to try at some point.

Thanks for your feedback Riad 👍🏽

We [meeting facilitators] agreed we should iterate which is why these changes are – hopefully – not too radical. We’re evolving the existing format rather than throwing it out and starting over. It’s good that you agree with that!

One thing I’m missing personally in this new format is the lack of a dedicated time to recognize and encourage new contributors specially

More than happy to consider including that as a new section, especially given how well it was received during the last editor chat.

One thing I’m missing personally in this new format is the lack of a dedicated time to recognize and encourage new contributors specially

Want to mention that there is a new contributor meeting that happens regularly too that should help cover this nicely as well: http://wayback.fauppsala.se:80/wayback/20220130162906/https://make.wordpress.org/meetings/

I agree though that we can do more to encourage getting started questions and making folks feel comfortable. Usually, when facilitating, I try to explicitly say “feel free to ping me if you want to speak up but might be nervous to” but not always.

Hey, I appreciate the focus on async status updates. As someone who hasn’t been able to attend lately due to personal reasons, I found the personal-updates format too overwhelming for me when I tried to catch up with what happened afterward.

The conclusions you shared make a ton of sense, and they align with my experience. Thank you for willing to iterate on the process to make it even more productive for all attendees.

I think iterating on the chat format is a good idea, and the new format makes sense to me.
My only concern with expanding the open floor is the danger of the core editor chat becoming a support chat where people report issues they are facing ( the ideal place for that is Github). Or where people raise attention to issues that, although important, were not worked yet because we did not have someone picking up the work.
I guess we should give priority to discussing topics that are actionable e.g: in the case of an issue where the people bringing the topic is able to work on a fix or design proposal and just wants validation on the path to increase the chance of the fix being fixed when ready.

I agree with Jorge, I do like the new format but also wanted to flag the risk that it could turn more into “office hours”. Otherwise, thank you for constantly iterating and improving the format of the meeting!

One iteration on the recommendation would be to add the status updates as comments on the agenda post (or alternatively on the summary post) as it might be difficult for someone to get a scan of all the high level status updates across ALL THE GITHUB ISSUES whereas reading a single post and its comments seems more reasonable.

Alternatively if there are tracking issues where those updates are posted in GitHub, then at least linking to each of them in the agenda and/or summary post would give folks an easy way to find/subscribe to those.

Hi @jeffpaul

Thanks for your feedback. It’s much appreciated.

We do already try to link to the Github tracking Issues in Core Editor summary posts. The main issue is making sure the Issues are kept up to date with progress as contributors have been used to sharing these directly during the chat.

I agree that having a high level overview in the summary pointing to well maintained and up to date updates in the tracking Issues in Github would be something to continue and to improve upon.

Thanks again.

Yep, so if we keeping including those tracking issues in make/core posts and updates are provided in those issues then that all sounds great (and definitely worth removing from the editor chat meeting itself to provide more time for discussion).

I’m all for these changes! My only note is ensuring that on quieter days we as facilitators have some resources to pull from to keep conversations flowing. For example, I think it would be great to pull a few in progress PRs to talk about or discussions from here as regular backup topics. The facilitator for the meeting or a volunteer could then recap as it’s helpful and post a comment on the corresponding area!

Performance team meeting summary 25 January 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus group updates

Announcements

@shetheliving

  • Three issues are open for voting here until Tuesday, February 1, 2022 at 06:00 PM UTC
  • What to do with issues that don’t fit into a specific focus/project?
    • Considered adding a “Misc” project, but that could be hard to maintain
    • Proposal: Add a “Misc” label and do not add to a project
    • If we see several related issues with “Misc” labels, we can discuss a new project/focus area
    • Proposal accepted; “Misc” label will be added

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

  • N/A

Object caching

@tillkruess @spacedmonkey

GitHub project

  • @tillkruess: Making good progress and project is organized.
  • @flixos90: We need to do a better job of going through performance-related issues in Trac. Will review these this week and ask others to do the same.

Feedback requested

Site Health

@audrasjb

GitHub project

Feedback requested

Measurement

@wp-source @josephscott

GitHub project

Feedback requested

  • N/A

JavaScript

@aristath @sergiomdgomes

GitHub project

  • @aristath: Still been focused on 5.9, but now that it’s released, will be able to refocus on this project. Think that focus should be on block themes and how blocks add scripts to the front-end. A lot of this was dependent on infrastructure included in 5.9. Could include things like optimizing their delivery, allowing themes & plugins to “attach” scripts to blocks, etc. Plan to go over blocks this week, find possible ways to improve how scripts work there, then compile a list of tickets we can work on in the Gutenberg repo, and start discussions in the performance plugin’s repo.

Feedback requested

  • N/A

Infrastructure

Feedback requested

  • N/A

Open floor

  • @craigfrancis: With ticket #52506, updating wpdb::prepare(), I’ve created my own basic performance testing page, and including a way of downloading the patch as a /wp-content/db.php file… I’m just wondering if I’m going about this in the right way?
  • @sergiomdgomes: Do we think of the performance plugin as a staging space for Core, or do we see it as a performance playground of sorts instead, which we share with the community? More concretely, which of these do we think are adequate or inadequate?
    • Experiments that may break some sites
    • Experiments that may worsen performance in some cases
    • Transitional experiments that are never intended to make it to Core because they’re too “hacky” or unstable
    • @flixos90: Most if not all modules should be intended for an eventual merge into WordPress core. IMO we shouldn’t build something into the plugin which we are already sure is a no-go for WordPress core based on what it does. We have an “Experimental” flag that each module can define and should be used for really early projects.
  • @pbearne: Should we add proof of concept code to the performance plugin that turns on a feature added to core that we expect plugins to handle in the future? For example, new core filters for get_all_options
    • @flixos90: Open an issue explaining a bit more along with a draft PR if helpful

Help wanted

#core-media, #performance, #performance-chat, #summary

Editor Chat Agenda: 26 January 2022

Facilitator and notetaker: @paaljoachim

This is the agenda for the weekly editor chat scheduled for Wednesday, January 26 2022, 03:00 PM GMT+1.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Hey! While working on Advanced Custom Fields support for the site editor, we’ve had issues trying to load things globally into the site editor iframe. We’ve got a workaround for our own css using `theme_file_uri` and `theme_file_path` to load plugin css inside `get_block_editor_theme_styles` (to avoid ssl issues with local environments if we let the `wp_remote_get` code execute by passing in a full URL to the plugin path), but this leads us to the following questions:

Is there a supported/recommend way to load things like dashicons into the site editor iframe?
Is there a workarounds/support for jquery-ui elements, like datepickers which don’t work in the site editor iframe due to hard coded references to window/document in their code.

Hello,
is there some event or Promise that will let us run unregisterBlockType so it will work in FSE editor, widgets and also on posts/pages?
this is not working for me
http://wayback.fauppsala.se:80/wayback/20220130162906/https://developer.wordpress.org/block-editor/reference-guides/filters/block-filters/#using-a-deny-list
This currently my solution, but it’s very “dirty”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
function dubebUnregisterBlockTypes(){
    Object.keys( dubeb_blocks ).forEach(function( key ){
        const blockName = dubeb_blocks[ key ];
        if( blockName && wp.blocks.getBlockType( blockName ) !== undefined ){
            wp.blocks.unregisterBlockType( blockName );
        }
    });
}
 
function dubebWaitForWrapper(){
    if( document.querySelector('iframe[name="editor-canvas"], .editor-styles-wrapper') ){
        dubebUnregisterBlockTypes();
    }else{
        setTimeout(function(){ dubebWaitForWrapper() }, 1000);
    }
}
 
if( typeof window._wpLoadBlockEditor != 'undefined' ){
    window._wpLoadBlockEditor.then(function(){
        dubebUnregisterBlockTypes();
    });
}else if( typeof window._wpLoadGutenbergEditor != 'undefined' ){
    window._wpLoadGutenbergEditor.then(function(){
        dubebUnregisterBlockTypes();
    });
}else{
    wp.domReady(function(){
        dubebUnregisterBlockTypes();
        if( ! document.querySelector('.editor-styles-wrapper') ){
            setTimeout(function(){ dubebWaitForWrapper() }, 1000);
        }
    });
}

also it will be very helpful if we would have disallowed_block_types_all filter similar (opposite) to allowed_block_types_all
currently when you use allowed_block_types_all you will receive first argument $allowed_block_types as TRUE boolean value, so there is nothing to filter… but the real problem is that when you use this filter, then you will automatically disable all potential future blocks that can appear after updates.

1
disallowed_block_types_all

would allow you to just disable some specific blocks without having this (negative) impact on other blocks

Check the year on the title and meeting notice link. Shows 2021? Saw this on a few other posts here also

Thanks Ishiv! Much appreciated! This post and a few others have been adjusted.

Hi,
I asked about this on Slack, but it was suggested to raise this here too:

I would like to know if there are plans to continue working on the Table Block.
It lacks support for the COLSPAN and ROWSPAN properties. Pasting tables with these properties will remove them, so there are no workaround.
A related issue was created in May of 2019, though there was no real progress.

Thank you.

The tracking issue for the Table block is here on GitHub
http://wayback.fauppsala.se:80/wayback/20220130162906/https://github.com/WordPress/gutenberg/issues/32400

And it is mentioned in Matias Ventura’s post Preliminary Roadmap to 6.0 as one of the focus areas.

I’d like to discuss the changes to the Core Editor meeting format as proposed by the Core Editor chat facilitators.

I don’t think it’s too radical and it could help make the chats more useful for contributors.

I’d like to have two items discussed:
1) Improving our PR merge > release process to ensure we’re capturing all the people who should be credited from a merge (e.g., helpful bug reporters, helpful issue commenters, helpful PR testers). Right now that does not appear to happen with regularity, but I’m not fully educated in the Gutenberg merge>release process and how best to capture this info to ensure it’s included in changelogs and eventual commits to WP core.

2) Getting review on http://wayback.fauppsala.se:80/wayback/20220130162906/https://github.com/WordPress/gutenberg/pull/38061 to see if that approach is appropriate for the related issue.

Dev Chat agenda for January 24, 2021

The weekly developers chat meeting will be held at 20:00 UTC in the #core channel on Slack. All welcome.

Summary from the last dev chat meeting on January 19.

1. Welcome

2. Announcements

Update: WordPress 5.9 Josephine – released on January 25, 2022
WordPress 5.9 Development Cycle

A WordPress 5.9 Release Candidate 4 took place on January 24, and marked the code freeze for the release. Help test WordPress 5.9 features

Read the latest Developer Notes

3. Blog posts to note

What’s new in Gutenberg 12.4 (January 19, 2022)

A Week in Core (January 24, 2022)

Join the discussion on 2022 release planning (December 27, 2021 post by @chanthaboune). New document coming

New additions to the agenda:

Preliminary Roadmap 6.0 (January 26, 2022)

Let’s talk about WordPress 6.0 post and video hosted by @annezazu – Hallway Hangout in #fse-outreach-experiment (December 21, 2021)

Do you have other posts that should get attention in the weekly dev chat? Please add them in the comments.

4. Upcoming releases

@hellofromtonya will share an update on the 5.9 release.

5. Component Maintainers

From next week, the weekly check-in with component maintainers will restart as contributors may be away this week after the 5.9 release launch. If you’re a maintainer who would like to get help with a blocker or share success/ collaboration, please feel free to either comment on this post or in the meeting.

6. Open Floor

You can add your topic to the comments below.

#agenda#core#dev-chat#week-in-core

#5-9, #agenda, #dev-chat, #week-in-core

A Week in Core – January 24, 2022

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between January 17 and January 24, 2022.

  • 25 commits
  • 33 contributors
  • 60 tickets created
  • 24 tickets reopened
  • 65 tickets closed

The Core team is currently working on the next major release, WordPress 5.9 🛠

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Administration

  • Properly handle HTML entities in the News & Events dashboard widget#41208

Bundled Themes

  • Bump the versions for bundled themes for release – #54783
  • Reverts [52549] (default presets in use by default themes) – #54782
  • Twenty Twenty-Two: Re-add the link to the theme’s HelpHub changelog – #54318
  • Twenty Twenty-Two: update the required version – #54318

Coding Standards

  • Use a more appropriate variable name in link_advanced_meta_box()#54856

Customizer

  • Remove Menus panel when a theme does not support menus – #54888
  • Remove Widgets panel when a theme does not support widgets – #54888

Date/Time

  • Add a unit test for the return type of current_datetime()#53484

Docs

  • Docblock corrections for get_block_file_template()#54879
  • Docblocks consistency fixes after [52604]#54690
  • Fix typos in some DocBlocks – #54729
  • Further update the send_retrieve_password_email filter documentation for consistency – #54690
  • Replace “Current theme” with “Active theme” in various DocBlocks – #54831, #54770

Editor

  • wordpress package updates – #54487
  • Bump editor packages to include the latest fixes – #54487
  • Update wordpress packages for WP 5.9 RC 4 – #54487
  • Update wordpress packages for WP 5.9 RC 3 – #54487

General

  • Clarify the deprecation messages in the _deprecated_*() functions family – #54658

Help/About

  • Update Freedoms page for 5.9 – #54270

Internationalization

  • Improve the context for color-related strings in WP_Theme::translate_header()#54804

Plugins/Themes

  • Allow to install/activate plugins/themes which require the WordPress version currently in development – #54882

Script loader

  • Prevent DB errors during Multisite install – #54800

Upgrade/Install

  • Update $_old_files for 5.9#54894

Users

  • Add new hooks to filter retrieve password emails – #54690
  • Revert the variable change in [52606] that caused the tests to fail – #54690

Props

Thanks to the 39 people who contributed to WordPress Core on Trac last week: @audrasjb (8), @costdev (6), @SergeyBiryukov (5), @hellofromTonya (4), @johnbillion (3), @talldanwp (3), @desrosj (2), @kjellr (2), @peterwilsoncc (2), @poena (2), @shedonist (1), @ryelle (1), @get_dave (1), @schlessera (1), @aristath (1), @kebbet (1), @connapptivity (1), @ocean90 (1), @sabernhardt (1), @sayedulsayem (1), @pbearne (1), @iandunn (1), @kpegoraro (1), @nickciske (1), @mukesh27 (1), @Presskopp (1), @davidbaumwald (1), @hellofromtonya (1), @mkox (1), @cbravobernal (1), @joen (1), @mamaduka (1), and @isabel_brison (1).

Congrats and welcome to our 3 new contributors of the week: @connapptivity, @kpegoraro, @mkox ♥️

Core committers: @sergeybiryukov (7), @audrasjb (5), @noisysocks (4), @desrosj (3), @peterwilsoncc (2), @davidbaumwald (1), @ocean90 (1), @jffng (1), and @hellofromtonya (1).

#5-9, #core, #week-in-core