Paal Joachim Romdahl 7:09 pm on January 31, 2022
Tags: , , , , ,   

Editor chat summary: 26 January, 2022

This post summarizes the weekly editor chat meeting (agenda here) held on Wednesday, January 26 2021, 03:00 PM GMT+1 in Slack. Moderated by @paaljoachim.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releases

What’s new in Gutenberg 12.4 (19 January).
Gutenberg 12.5.0 RC1 released.

WordPress 5.9

WordPress 5.9 was released 25th of January!

Key project updates

Based on the scope for Site Editing projects.

Site Editor and Patterns

Have no official updates at this time.

@get_dave

Tracking Issue status update
We’re very keen to hear feedback on the block and also what folks would like to see added in the future. Drop in to (SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel) #feature-navigation-block-editor to let us know.

Global Styling

@jorgefilipecosta

  • One of the focus is documenting and making sure new contributors can be on-boarded and contribute to its engine.
  • There was also lots of progress on the style variations project.

Mobile Team

@hypest

In Progress

  • Finalizing GSS Font size and line height.
  • Add more integration tests (reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.-native-testing-library based).
  • Prepare to pick up other projects.

Components Team

@mciampini

Task Coordination

@jeffpaul

@santosguillamot

@amustaque97

@mamaduka

  • Collaborated with @joen on some last-minute Pattern preview fixes. It’s not perfect, but it’s definitely an improvement. We will improve UXUX User experience here in a minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality..
  • There’s another PR for Pattern previews fixes and is looking for testers.
  • I’m also looking for feedback for Plugin error boundaries in editors.

Open Floor

Announcements, questions and discussions.

@bph

Announcement: Developer Hours.
We have the first event scheduled on WordPress Social Learning space on Feb 8 at 11am / 16:00 UTC with an awesome panel with @fabiankaegy @karmatosed and @Nick Diego .

@KubiQ

Question:
What about unregisterBlockType ? Currently there is documentation but it’s not working for widgets screen and FSE editor. Check out the discussion on Slack.

@markhowellsmead

Question:
I’m trying to make a start on a new theme using 5.9 and without the Gutenberg plugin. Is there anything I need to do to get changes in theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. to load? (e.g. reset a cached version?) Check out the discussion on Slack in this tread.

@Liam Gladdy

Question:
Here from the Advanced Custom Fields dev team. We’ve been working to bring compatibility with the site editor and it’s iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. but have hit a stumbling block of trying to load assets in. Things like dashicons and jQuery UIUI User interface elements like date pickers don’t work because they’re only loaded in the global context, and are hard coded to the document or window object. We’ve considering loading them again manually on the late block_editor_settings_all filter, but that feels wrong… Is there a recommended way forward? Check out some of the feedback on Slack.

@jeffpaul

Improving our PR merge > release process to ensure we’re capturing all the people who should be credited from a merge (e.g., helpful bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reporters, helpful issue commenters, helpful PR testers). Right now that does not appear to happen with regularity. Check out feedback on Slack.

@paaljoachim

I would like to bring up is that we as in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor facilitators have been looking at ways in how we can improve the core editor chats. Do please check out the post proposed improvements to the core chat agenda and format.

#core-editor, #core-editor-summary, #gutenberg, #meeting-notes, #summary

Bethany Chobanian Lang 4:12 pm on January 31, 2022
Tags: , , ,   

Performance Chat Agenda: 1 February 2022

Here is the agenda for this week’s performance team meeting scheduled for February 1, 2022, at 16:00 UTC.

This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Jonathan Desrosiers 1:21 pm on January 31, 2022  

Ensuring Proper Attribution for Contributions to WordPress on GitHub

One of the greatest things about open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. is that contributions come in many shapes and sizes. Anyone can contribute regardless of skill set, experience, time zone, or background. There are countless ways for someone to get involved with open source projects.

WordPress is no different. Contributors submitting code modifications are only a small subset of the larger community. Recognizing all types of contributions is essential to establishing a healthy contributor base, and the responsibility falls on the project’s maintainers. Contributors that feel recognized and valued are more likely to continue contributing.

There is an established and documented policy on the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. side of the project to ensure that everyone contributing to a changeset receives credit (or “props”). This method has been in place for over ten years now and makes generating the list of props for each release scriptable and straightforward. The process is a bit unique to the project but frequently receives positive feedback from others in open source.

Since being merged into WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in version 5.0, there has not been an equivalent process for the contributions on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. The process is manual, does not account for non-code contributions, and often results in contributors not receiving credit for their work.

This post summarizes the current processes in place for Trac/SVN and GitHub to understand the shortcomings and propose a small change to ensure more people receive proper attribution for their contributions made on GitHub.

Current Processes

Trac/SVN

When a commit is made to the WordPress source code in SVN, the person committing the code is responsible for collecting a list of WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ users that contributed to moving a ticketticket Created for both bug reports and feature development on the bug tracker. towards a resolution.

Props should be given to all those who contributed to the final commit, whether through patches, refreshed patches, code suggested otherwise, design, writing, user testing, or other significant investments of time and effort.

WordPress Core Handbook – Commit Message Guidelines

The guidelines also encourage committers to “err on the side of giving props liberally. Props provide major encouragement for contributors.” Commits themselves are considered a contribution, even if the committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. does not include their name in the props list (see the section on self props).

When a release is near, all of the commits in the current release cycle go to a text file via git log, and a private script parses out every “Props x, y, z.” line to tally up the number of props for each contributor. After this, the list is groomed for duplicates and incorrect usernames/typos.

GitHub/GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/

There are currently no documented best practices for giving props on GitHub. There are two primary ways that props are currently given: when merge commits occur and when Co-authored-by trailers are added to merge commit messages.

Here is the current process for gathering props when a WordPress release approaches:

  • Use git shortlog to dump commit data into a text file. For 5.9, the command was git shortlog -sen v10.8.0...v11.9.0 > 5-9-gutenprops.txt
  • Use git log to dump commits with Co-authored-by trailers into a text file. For 5.9, the command was git shortlog -sen v10.8.0...v11.9.0 > 5-9-co-authored-gutenprops.txt
  • Grab props for pull requests merged after the final Gutenberg release included that have been backported. This is usually done manually, but could maybe be accomplished using git shortlog in the respective wp/X.X branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". (provided the commits were cherry picked correctly) and repeating the Co-authored-by step above for that branch.
  • Manually merge the three lists while combining duplicates.
  • Match all GitHub contributors with their WordPress.org account. This can be semi-automated for contributors that have linked their .org and GitHub accounts but still requires manual interaction as many folks have not linked their accounts (but please everyone, link your accounts).
  • Merge this list into the Trac/SVN props list generated in the previous section, combining duplicates.

Finalizing Props List

After both processes are completed above, the release squad will attempt to manually verify that contributors with non-code contributions are also represented in the list.

Pain Points

In summary, these are the pain points for collecting props from GitHub:

  • Highly manual and time consuming.
  • Often requires multiple people to divide and conquer username matching (especially when a contributor has not linked their w.org account to their GitHub one).
  • Non-code contributions never receive props, unless a Co-authored-by trailer is added or they are added during the finalization step.
  • The contributions of all contributors are often under-represented, if not missed entirely.
  • Contributions are sometimes double-counted when the Core committer also compiles props for the package update commit (see [52633] as an example).
  • Props counts for the Trac/SVN side are often higher than the GitHub side because of better tracking with SVN commit messages and respective prop guidelines.

Proposed Changes to GitHub Processes

The following change is recommended to standardize and improve the process of giving all community members props for their contributions.

When a Gutenberg pull request is merged, the contributor merging changes into the code base will be responsible for reviewing the PR, and any associated issue(s) or draft/closed PRs to identify all contributors who should be credited on the merge commit by following the same process and guidelines as WordPress Core SVN and adding a “Props user1, user2, user3.” line in the merge commit message.

The same guidelines should be followed as SVN commits. They’re listed below for clarity with new lines specific to GitHub in bold, and irrelevant items specific to w.org omitted:

  • Must be preceded by a blank line.
  • GitHub usernames should be used, not WordPress.org usernames.
  • Usernames must not start with an @ (at) sign.
  • Separate usernames by comma + space. Think: /^props (\s*([^,]+),?)+$/
  • Copy/paste usernames to avoid typos.
  • Err on the side of giving props liberally. Props provide major encouragement for contributors.
  • If you forget to prop someone, check to see if they already have props in the current release as it won’t matter in the long run as they’ll be included in the release credits anyway. If they aren’t already propped, you can flag it to the Release Coordinator to ensure that person is added on release day. It’s also recommended to reach out to the contributor in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. or in a comment on the ticket as a courtesy and apologize for missing their name in the commit message and letting them know their contribution will be recognized and note how.

Pros

  • Allows for manually auditing the list of contributors. This helps give proper credit to testers, bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reporters, and other non-code contributors and also prevents giving props to anyone that does not positively contribute to the solution.
  • Consistency between SVN and GitHub
  • Allows the same w.org props script to be adapted and used for GitHub props, greatly reducing the amount of manual work required. https://profiles.wordpress.org/github:username can be used to easily look up a GitHub contributor’s w.org username (provided they have linked their accounts). Example: https://profiles.wordpress.org/github:desrosj.

Cons

  • Requires the merging contributor to manually compile a list of contributors (though this same con exists on SVN wherein the committer needs to compile the list from Trac).
  • Does not show up on user contribution graphs in GitHub.

Why not the Co-authored-by trailer?

On the surface, the Co-authored-by trailer seems like the ideal solution, and even shows up on a contributor’s profile activity feed. However, there are several shortcomings.

  • It’s GitHub-specific. If there’s a need to use another GITGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. service in the future, the process for giving props would need to be revised.
  • Co-authored-by trailers can only be added to commit messages easily when using GitHub Desktop. When merging a pull request through the website, the merging contributor still needs to manually compile a list of names and emails for anyone that contributed.
  • This method includes emails in the commit message. While users can choose to keep their email address private in their GitHub settings and emails are accessible through git log, making an email to reach out to a specific contributor more easily accessible is not ideal.
  • Emails and legal and preferred names change. Usernames are far less likely to change.
  • Since commit subject lines only are used when squashing and merging pull requests, the Co-authored-by trailers found within any commit message on a PR are stripped out of the final commit message. The merging contributor needs to re-add them and manually look through each commit for Co-authored-by trailers.

Other Potential Solutions Ruled Out

Next Steps

After discussing this proposal, fielding all questions, and addressing all concerns, these are the next steps required:

  1. Educate the maintainers of the Gutenberg repository and help them make this adjustment in their workflow.
  2. Add merge commit details to Gutenberg’s Repository Management > Merging Pull Requests documentation.
  3. Update the Core handbook page for Preparing the About Page > Props documentation.
  4. Update the Core handbook page for Commit Messages, referencing the Gutenberg Merging Pull Requests documentation.
  5. Adjust the script on w.org responsible for compiling the list fo props for a release to also ingest a git log with GitHub usernames.
  6. Explore potential ways to automate props collecting with GitHub Actions (a workflow that collects all participants for the pull request and attached issues, etc.).

Other Resources

  • MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. tickets for gathering Gutenberg props: 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.0.

Props @jeffpaul, @sergeybiryukov, @cbringmann for pre-publish review.

Birgit Pauli-Haack 5:10 pm on January 28, 2022  

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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., 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, blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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.

marybaum 3:17 pm on January 28, 2022
Tags: , , ,   

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.

Blogblog (versus network, site) 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

The day after dev chat on Thursday, @chanthaboune published Proposal: 2022 Major Release Timing. Take a look and add your thoughts there!

Major releases

@hellofromtonya congratulated everyone on the historic release and shared that after ten million downloads in the first 24 hours—ten million!—TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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 ticketticket Created for both bug reports and feature development on the bug tracker. #52506, which updates `wpdp::prepare()` to escape identifiers safely. There were emoji equivalents to a bevy of oohs and ahs from the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/? Pretty cool, I say. — MB

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

Josepha 10:40 pm on January 27, 2022
Tags:   

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 pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @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

Tonya Mork 9:38 pm on January 27, 2022
Tags: ,   

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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

Matias Ventura 9:10 am on January 26, 2022
Tags: 6.0,   

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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/: Phase 2. This doesn’t mean the customization phase would be concluded with it, but that its main features would have been established.

Tracking Issue to follow →

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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.. 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 jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. 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 sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.; 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. 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

David Smith 9:08 am on January 26, 2022
Tags:   

Proposed improvements to the Core Editor chat agenda and format

This post was coauthored with (some of) the facilitators of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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 GithubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.

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 contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. 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

Bethany Chobanian Lang 10:28 pm on January 25, 2022
Tags: , , ,   

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 February 1, 2022 at 6pm GMT
  • 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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. 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

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repo, and start discussions in the performance pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’s repo.

Feedback requested

  • N/A

Infrastructure

  • @flixos90: Opening an issue soon to discuss the scope of the initial plugin release. We already have a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ action to eventually deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. this to wordpress.org, but which account should we use for that deployment?
    • Some ideas outlined here: https://github.com/WordPress/performance/issues/42
    • Proposal: Create an account not tied to an individual contributor, e.g. performanceteam. Proposal accepted and @flixos90 will create the new account.

Feedback requested

  • N/A

Open floor

  • @craigfrancis: With ticketticket Created for both bug reports and feature development on the bug tracker. #52506, updating wpdb::prepare(), I’ve created my own basic performance testing page, and including a way of downloading the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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