Carike 2:08 pm on April 18, 2021
Tags:   

Proposal: Treat FLoC like a security concern

Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.

TL;DR: FLoC places people in groups based on their browsing habits to target advertising.

Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.

This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.

So What Now?

WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with four lines of code:

function disable_floc($headers) {
    $headers['Permissions-Policy'] = 'interest-cohort=()';
    return $headers;
  }

add_filter('wp_headers', 'disable_floc');

What About Admins Who Want FLoC?

Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.

Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.

What Do You Mean By “Treat It Like A Security Concern”?

  1. Include 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. the next 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., rather than waiting for the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.;
  2. Back-port the patch to previous versions of WordPress.

Why Treat It That Way? Why Not Just Wait For The Next Major Release?

Well, keep your eyes peeled, because there is a ticketticket Created for both bug reports and feature development on the bug tracker. for future releases on its way!

While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.

Request For Comment

Please join the discussion below!

Version Control:
Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).

#core-privacy

Josepha 3:39 pm on April 15, 2021
Tags: ,   

Full Site Editing Go/No Go | April 14, 2021

TL;DR

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/ 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 shipped v10.4 yesterday, April 14th, and Matías hosted the go/no go demo to review the current state of Full Site Editing and determine what, if anything, should be included in WordPress 5.8 (July 2021), as described in my earlier post.

The demo lasted close to 1.5 hours; it’s impressive to see how far Gutenberg has come. It was evident in the demo how powerful Full Site Editing can be. There is plenty to iterate upon and refine, but from a high level perspective all participants felt this was a “go” for WP5.8. Listed below are the primary areas to focus our collaborative efforts on, as well as a full list of issues/questions raised in the demo. With the cadence of Gutenberg updates there should be three major releases of Gutenberg (10.7) before the feature freeze date for WP5.8 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..

The changes that Phase 2 bring to WordPress are substantial, so to avoid overwhelming users the Global Styles interface and Site Editor (managing all templates) will ship post-WP5.8. This also gives more time for more theme authors, plugin developers, agencies, designers, site builders, and the like to explore and provide feedback.

WP5.8 Go ✅

  • Improvements from Gutenberg 9.9+.
  • Introduce new blocks (Query, Site Logo, Navigation, etc).
  • theme.json mechanism.
  • Template Editor for Pages/Blank Template.
  • Widgets Screen & 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. widgets in CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings..
  • Design tools: Duotone, Layout controls, padding, etc.

Not all of the above are currently ready but there’s some level of confidence that they can be by the time of 5.8.

Who Attended

  • Matt Mullenweg – Project Lead (advocating for the vision/mission of WordPress, and aggregate body of users)
  • Matías Ventura – Gutenberg project lead (host of the demo)
  • Helen Hou-Sandí – Lead developer (advocating for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and extender community)
  • Josepha Haden Chomphosy – Executive Director (advocating for the community of WordPress, and aggregate body of users)
  • Héctor Prieto – Technical Project Manager (following up on technical action items)
  • Chloé Bringmann – Assisting with administrative and operational logistics

Reflections and Action Items

Listed below are synthesized suggestions and comments from the conversation.

Pattern Directory

  • While the directory is not ready yet, iterations will continue. More available patterns will be necessary, if it is to live up to its potential.

Query Block

  • Perhaps rename Query along the lines of, “Block List.”
  • Define the “query” of query block, and refine nomenclature for users.
  • When selecting a pattern, it’s not clear that what you see is an example and that you still need to select which pattern you want. Iterate on UIUI User interface.
  • Multi-entity saving flow is not clear, as when you don’t save some entities’ changes nothing tells you what happened, and unselected changes aren’t actually discarded, just not saved in the background.
  • Iterate on the best placement for block names.
  • The “inherit query” text is not clear, both from a technical standpoint and a jargon standpoint. We need to aim for the right type of verbose so that it’s clear and descriptive.
  • 🚩 This is potentially too powerful for users—you can edit everything from the blocks in this block. Flag was seconded.

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.

  • When options aren’t available in the UI because they have been disabled by the theme, make it clear that the options are turned off.
  • theme.json should allow a primary block to declare the styles for any nested blocks (like a search block within the nav block).

Inserter

  • The slide-in inserter makes the canvas smaller, so when adding full-page patterns they don’t look the same as in the preview until the inserter is closed again. Add the possibility for the inserter to show the patterns in the canvas in a zoomed-view rather than in a responsive view.

Navigation

  • We need more user-testing of both the Navigation Block and the Navigation Editor.
  • Move most of the block popups to the toolbar like when cropping images in the Image Block. E.g., links are not visible until you edit them.

Other

Next Steps

With this outline for the WP5.8 scope, look for a plan to prioritize and address these issues in the coming days.

Recording

April 14, 2021 Recording

Thank you to @cbringmann, @matveb, and @priethor for their work on getting this content processed and ready to ship.

Transcript

Continue reading →

#5-8, #core-editor

Francesca Marano 6:58 pm on March 30, 2021
Tags: ,   

5.8 Pre-planning

Following Josepha’s early thoughts on 5.8 planning, I am kicking off the pre-planning phase of WordPress version 5.8.

Full site editing in 5.8

The plan for WordPress 5.8 is to merge and release the minimum viable product (MVP) of full site editing (FSE). This makes this release particularly complex to handle. It’s a new, exciting change, and it needs the appropriate time to marinate in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for contributors with enough time to work on it.

Schedule

I would like to propose the following schedule.

MilestoneDateDays from
AlphaFebruary 23, 2021
First FSE go/no go dateApril 13, 2021
Second FSE go/no go dateApril 27, 2021
(If go) FSE MergeTo be determined, but as soon as possible after being greenlighted
Feature freeze/Bug FixesMay 25, 202191 days after Alpha
BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1June 8, 202114 days after Feature Freeze
Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1June 29, 202121 days after Beta 1
General releaseJuly 20, 202121 days after RC1

What’s this “Feature Freeze” step?

As previously discussed (first post, second post), mixing defect work and beta testing is not great for a number of reasons:

  • As a project, we want to respect the beta testers efforts by not introducing new bugs (defect work fixes) in areas they’ve already tested.
  • A mature software project has a beta period during which the focus is on testing changes made during alpha period to ensure its stability.
  • Having a separate deadline for enhancements/features and bugs is beneficial to allow developers to switch focus after the first deadline to address a slew of outstanding bugs.

Enter the “Feature Freeze” step: two weeks where contributors and committers can take care of the thousands of defect tickets in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

This process should allow time to dedicate appropriate attention to those tickets, without taking attention and resources away from beta testing, which needs to be a priority, especially in this release.

Squad

With such a complex release, Core needs a group of experienced contributors leading the release. For this release, the ride-along/mentorship will pause so that the leads, with previous experience in releases, can focus on the process.

Pre WP5.8 Squad – Skeleton Crew

The period leading to the go/no go step, will need a minimal squad that will focus on:

  • 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. hunting for WP5.7.x minor releases
  • triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and group tickets into future milestones
  • test Core and FSE tickets and PRs

We are kicking off with a minimal squad of three roles:

Full Squad

Once we’re past the go/no go dates the skeleton crew, together with the project leadership, will determine which skills are needed to successfully complete the cycle.

What about scope?

The focus of the release is full site editing. As suggested in the recent FSE FAQ, the specific scope is to merge the interface that allows for template interaction outside of content, as well as 20+ new blocks, and design tools. This part of the FSE merge will not be offered to users by default, but instead will be geared toward our extender community (theme authors, 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 developers, agencies, builders, etc) so that they can experiment with their users in mind.

As with other releases, it is possible to include more features, provided someone can spearhead them.

I will start a round of check-ins with component maintainers as soon as the timeline is confirmed.

#5-8, #planning

Francesca Marano 10:21 pm on April 13, 2021
Tags: , , ,   

Dev Chat Agenda for April 14, 2021

Here is the agenda for this week’s meetings to occur at the following times: April 14, 2021 at 5:00 UTC and April 14, 2021 at 20:00 UTC.

Release Announcements

Blogblog (versus network, site) Post Highlights

Blog posts that need feedback

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

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

#5-7-1, #5-8, #agenda, #dev-chat

Paal Joachim Romdahl 9:54 pm on April 12, 2021
Tags: , , ,   

Editor Chat Agenda: 14 April 2021

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, April 14, 2021, 04:00 PM GMT+1.

This meeting is held in the #core-editor channel in the Making WordPress 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/..

  • 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/ 10.4 release.
  • Full Site Editing Scope for WP5.8
  • Monthly Plan for April 2021 and key project updates:
    • Global Styles.
    • 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. based WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor.
    • Navigation block.
    • Full Site Editing.
  • Task Coordination.
  • Open Floor.

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

  • 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

sarayourfriend 12:45 pm on April 9, 2021
Tags:   

Follow up to the native TypeScript proposal

The proposal to intentionally integrate native TypeScript into 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/ repository has garnered overwhelmingly positive feedback so far. However there have been some responses that express concerns over introducing a new technology that will be difficult for contributors to understand. This follow up will hopefully address some of those concerns by refining and clarifying some of the ideas in the original proposal.

In this proposal, nothing changes for consumers of Gutenberg packages (like 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. developers). 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/. remains the primary way of interacting with the 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.. If block developers opt-in to use TypeScript for their own projects, we will gradually improve the tools and typings to make their experience better.

Okay, let’s answer the question: when will TypeScript be used in the repository? To answer this question, we must first keep in mind that we do not refactor without a good reason and certainly not for refactoring’s sake alone: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/#code-refactoring

“Code refactoring should not be done just because we can”

Let’s remember why it’s important to introduce TypeScript and strongly typed functions:

  • A better developer experience via automatic code completion (like Intellisense) and other related tools
  • More confidence in our code through better static analysis of function internals and their usages

When to use TypeScript for existing code

So, with that in mind, I’d like to propose @gziolo’s method for approaching when to use TypeScript for existing files:

  • The default is to use JavaScript
  • When it is possible to type something simply with JSDoc, use JSDoc
  • If there are complex types, but JSDoc is still sufficient generally for consuming those types, you may extract the complex types into a types-only types.ts file to be imported into the JSDoc
  • If it is not possible to express the types using JSDoc or if the JSDoc will vastly over-complicate the ability to type a function, convert it to TypeScript

This, of course, only applies to the places that support native TypeScript anyway which is currently limited to mostly lower level packages, which are the primary initial targets for typing. This falls in line with the original proposal’s statement that “the majority of Gutenberg will probably forever remain as plain old JavaScript.”

It does not cover the case for fully new code in existing packages or new code in the form of completely new packages.

When to use TypeScript for new code

Therefore, for the now rare occasion when a fully new package is added, if all the dependencies are typed, I would like to propose that these should be added in native TypeScript. Likewise, packages that are fully typed or are currently being worked on towards full typing (see #18838 for the list of typed and in-progress packages) and fall into the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of “lower level packages” as described here and in the next section should have new code added in TypeScript.

Otherwise, new code should follow the the same logic laid out above for existing files, essentially only using TypeScript when absolutely necessary, preferring JSDoc typed JavaScript.

Lower level packages

A note about “lower level packages.” We can refine this definition slightly by stating that a low level package is a package that:

  1. Provides a public API; and
  2. Is not frequently contributed to.

Summary

In summary, I’d like to propose the following:

  • When refactoring existing code to add types, follow the script above.
  • For new packages, use native TypeScript when a) all the packages dependencies are typed and b) when they fall into the category of “lower level packages” as defined above.
  • For new code in existing packages, follow the same script above as for refactoring existing code.

If this is accepted by the community then I will open a PR to update the JavaScript coding guidelines in the repository to reflect this. The update will include the script set out above.

When will a decision be made?

I’d like to aim for making a decision 2 weeks from the date of publication of this follow up post. That should give ample time for discussion and questions.

#javascript

Josepha 7:54 pm on April 8, 2021
Tags: , ,   

Full Site Editing Scope for WP5.8

The first go/no go date is next week (April 14, 2021), and I’d like to offer a roadmap and some high level clarifications for folks following along.

Full site editing is a collection of projects and together they represent a big change, arguably too much for a single release. The most important context to share is that it isn’t shipping as the full, default experience for users. One of the clearest pieces of feedback from the Phase One merge process was that there wasn’t enough time for our extenders (agencies, theme authors, 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 developers, site builders, etc.) to prepare for the upcoming changes.

With that in mind, this merge process won’t be an on/off switch. The focus now is not on a full and nuanced user experience, but more of an open public betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. within WordPress 5.8.

With that context, let’s take a look at what is coming up in the next week and beyond..

Next Steps

Go/No Go Dates

On April 14 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/ plugin will ship v10.4 and shortly thereafter will be the go/no go demo.

The scope is the same as the past few months and focuses on the interface that allows for template editing, a number of new theme-building-oriented blocks, and design tools. This part of the FSE merge will not change the users’ default experience, but instead will focus on bringing tools to the extenders in our community so that they can experiment with their users in mind.

  • Block theme building based on the theme.json configuration file. (https://github.com/WordPress/gutenberg/issues/29891)
  • Site-editing-oriented blocks, such as the Query block, Template Part block, and Site Logo block.(https://github.com/WordPress/gutenberg/issues/28744)
  • Along with the query block, a collection of patterns and contextual pattern transformations. (https://github.com/WordPress/gutenberg/issues/30508)
  • 7 Gutenberg plugin iterations (10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6)

Beta Dates

On June 8 the WordPress 5.8 release will reach its beta period. 

The components below are some of the most complex, and the user experience of them will be key. They are all high priority to complete (hopefully for WP5.8), but will be punted if they aren’t ready in time for Beta.

Later Dates

On July 20 the WordPress 5.8 release will reach general availability.

The components below came up frequently in user testing as being confusing and need more attention. Polishing these components has been moved out of the focus for WP5.8 for proper prioritization.

  • Making the saving flow more intuitive when in the template editor and making changes to multiple areas of a site.
  • Phased rollout of user-interface for Global Styles and interactions with the template editor & template parts.

The Demo

This has been scheduled for April 14. 

Attending

  • Matt Mullenweg – Project Lead (advocating for the vision/mission of WordPress, and aggregate body of users)
  • Matias Ventura – Gutenberg project lead (host of the demo)
  • Helen Hou-Sandi – Lead developer (advocating for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and extender community)
  • Josepha Haden Chomphosy – Executive Director (advocating for the community of WordPress, and aggregate body of users)

Agenda

  • Matias will demo the features intended for WP5.8
  • Discussions and implementation questions

Afterward

  • Blocking items (if any) will be gathered and shared publicly
    • If yes: A plan to prioritize and address issues prior to the second go/no-go date of April 27 will be shared
    • If none: A plan to merge to Core will be shared

#5-8, #core-editor, #full-site-editing

Bernhard Reiter 3:23 pm on February 19, 2021
Tags: , e2e tests, end-to-end tests, , hallwayhangout   

Hallway Hangout: Fool me once — Writing end-to-end tests against regressions

On Thursday, I hosted a little walkthrough on how to write a simple end-to-end test to make sure a specific piece of editor functionality that had broken in the past wouldn’t break again.

As 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/ grows, the project sometimes experiences regressions: Features that used to work suddenly don’t anymore. In order to prevent these regressions from happening, contributors can write end-to-end (e2e) tests that cover a given piece of functionality and alert us when that functionality is broken. Combined with a Continuous Integration system such as 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/ Actions, this is a very powerful tool, since it can notify a PR author that their PR might break something before they even merge that PR.

I’ve recently tried to keep more track of such regressions, and have started filing issues requesting e2e tests to cover them. In the hangout, I’ve picked one of these issues and demonstrated how to write an e2e test for it.

Continue reading →

#core-editor, #e2e-tests, #end-to-end-tests, #gutenberg, #hallwayhangout

glendaviesnz 4:41 am on March 23, 2021  

Gallery Block Update – Call for Testing

A refactor of the core Gallery Block has been worked on over the last couple of months which will move it from a list of image tags within 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. content to nested Image blocks using InnerBlocks. The hope is this change will make things easier for both users and developers.

Why the change?

The fundamental reason for this change is to make images behave the same in the editor whether they are used as single blocks or as part of a gallery. For example, for users, this update means that Gallery images would automatically have the ability to add custom links for each image! It’s also easy now to replace a single image directly. Other benefits include being able to use the standard move, drag and drop, copy, duplicate, and remove block functionalities. Keyboard navigation also benefits from the standard block model.

There have been open issues related to this inconsistency for some time:

To get around this inconsistency, 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 developers often have to duplicate all of the Image block functionality in custom Gallery block plugins. Tied to this, plugins that extend the image block haven’t been able to benefit galleries directly. With this change making image behaviour more consistent between stand-alone images and those within the gallery, more custom gallery functionality can be implemented as Block Styles or Block Variations of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Gallery block instead of creating a completely new gallery block.

With each image being a block, server operations are also much more straightforward since you can get the image IDs directly.

In depth testing needed

While the expectation is nothing changes in terms of output for the end-user, this is a pretty major change on a technical level for a very popular block, including a change in the underlying markup to align it with the W3C WAI guidelines on the grouping of images, so it’d be a huge help to gather as much testing feedback as possible.

Accessing the new Gallery Block

To test the new Gallery block, you can either checkout the Gallery refactor PR branch and test in a local dev environment, or you can download the Gallery refactor plugin build and install it on any WordPress test site. Once installed you need to enable the experimental setting ‘Enable the refactored gallery block’:

Only new gallery blocks added after the experimental flag is turned on will be in the new format, all existing galleries will be editable and viewable in the current format. You can manually transform an old format gallery to the new format using the block transform menu and choose the ‘Gallery’ option.

Important note — only run the Gallery refactor experimental feature on test data

Although any existing gallery saved content should be unaffected, if you transform these to the new format, or add new gallery blocks in the new format, these blocks will be broken if the experimental feature is removed …. so don’t run the gallery refactor build against any critical data that you don’t have a backup of.

How can I be sure I am seeing the new gallery block?

When adding a Gallery block with the refactored gallery, selecting an individual image in a gallery should show you the same options as for an individual Image block. Currently, the only settings that will be missing are align and resize as these options break the gallery column layout.

Please note that this experimental feature will not currently work in FSE templates. To see the new gallery block you will need to add the block to a standard post or page. This change is also not ported to native mobile builds yet.

What needs testing?

General testing

Here’s a list of areas of functionality that need testing for your convenience that anyone can help test.

Plugin and theme authors

If you are the author of a plugin or theme that extends or restyles either the Image block or the existing Gallery block you should:

  • Test how running the new Gallery block format affects the display of existing content in the editor or front end.
  • Test your plugin or theme against an existing gallery that has been migrated to the new format.
  • Test with new galleries added with the refactored block.
  • Test how an Image block extensions affect layout, etc. if the Image block is nested within one of the new Gallery blocks.

Where to report issues

Please leave feedback in the comments of this post. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly 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/. If you leave feedback in 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/, please do still comment below with the link. Please check against the known issues list before reporting.

Robert Anderson 7:58 pm on February 23, 2021
Tags: , ,   

Inner Blocks API Changes

The majority of 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. authors prefer to keep the focus on the parent block upon insertion in the editor rather than move it to one of the child blocks. Prior to WordPress 5.7, the default behaviour is the latter. In WordPress 5.7, the default behaviour has been changed to be the former.

This simplifies the 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. and means that the behaviour of the following APIs has changed:

  • InnerBlock component
  • useInnerBlocksProps hook
  • replaceInnerBlocks action

InnerBlock component and useInnerBlocksProps hook

Both handle the focus on the blocks with templateInsertUpdatesSelection property. If you want to keep the focus on the parent you can omit this property.

If you want to move the focus to the first child block you have to set this property to true.

Example:

<InnerBlocks template={ [ [ 'core/heading' ] ] } templateInsertUpdatesSelection />

const innerBlocksProps = useInnerBlocksProps(
	{ className: 'wp-block-cover__inner-container' },
	{
		template: [ [ 'core/heading' ] ],
		templateInsertUpdatesSelection: true,
	}
);

replaceInnerBlocks action

Reference: https://developer.wordpress.org/block-editor/data/data-core-block-editor/#replaceInnerBlocks

This action handles focus with the third argument updateSelection. If you want to keep the focus on the parent you can skip this argument when calling replaceInnerBlocks.

If you want to move the focus to the first child block you have to pass this argument with true value. Examples:

replaceInnerBlocks( rootClientId, blocks, true )

This dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. was written by @ntsekouras and edited by @noisysocks.

#5-7, #block-editor, #dev-notes