Proposal: Stop merging experimental APIs from Gutenberg to WordPress Core

This call for feedback will be open for the next four weeks until September 7th.

I propose a way of harmonizing the process of merging new APIs from 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 to the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Right now, the two projects have very different policies, confusing contributors and sparking lively discussions on every major WordPress release. 

Today, experimental APIs are merged to Core and sometimes removed later

To date, 280 experimental APIs were merged from the Gutenberg plugin to WordPress Core. That’s problematic, and here’s why.

WordPress values backward compatibility. Upgrading to a new version should not break the plugins and themes, so WordPress public APIs these plugins and themes depend on are maintained across major versions. As the WordPress handbook states:

Historically, WordPress has been known for preserving backward compatibility across versions. 

The Gutenberg plugin values agility. It’s the safe space where new experiments are planted and grow into stable features without the same stability constraints. It is okay to ship a prototype, learn from it, and then start over again. New functions under active development often include the __experimental prefix in their name to indicate they may change at any point and shouldn’t be relied upon. Removing the obsolete code also makes the 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/. bundle smaller and reduces the editor loading time. As the Gutenberg plugin handbook states:

Experimental and unstable APIs are temporary values exported from a module whose existence is either pending future revision or provides an immediate means to an end.

In the Gutenberg plugin, it’s fine to remove these experimental APIs. In WordPress, it’s not. Unfortunately, many have already been released with major WordPress versions.

Tomorrow, experimental APIs could be restricted to the Gutenberg plugin and never merged to Core

Let’s remove the experimental prefix before merging new APIs into WordPress Core.

This way:

  • Core can deliver the expected level of Backwards Compatibility
  • The Gutenberg plugin can retain the freedom to remove the experimental APIs as needed
  • The experimental APIs would get audits
  • It would make the release easier

What if a stable feature depends on an experimental feature?

Then it isn’t actually stable. Let’s stabilize the dependencies first.

What about the existing experimental APIs?

Most of those already merged to Core would get a stable alias. It would preserve BC and shouldn’t noticeably affect the bundle size. Some will need a different treatment; let’s discuss that case-by-case.

What if an existing experimental 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. already in Core needs to be removed?

Do we? If so, let’s consider that on a case-by-case basis. There are established Core practices like contacting plugin authors, writing make Core posts, preferring soft deprecations, and so on. I don’t expect to see many instances of this.

What if a future stable Gutenberg plugin API really needs to be removed after it’s released in Core?

Yes, it will happen. Let’s acknowledge and embrace it. Some good reasons were mentioned in the GitHub discussion, and the future will surprise us with many new ones. Again, let’s follow the established Core practices. For example, deprecated.php shows that removing a function body is sometimes okay as long as the name keeps working.

What are the downsides?

I can see two:

  • Some Gutenberg plugin features will get merged into the Core later that they currently would be. The total amount of the development work won’t change, but the merging timeline will. That could be a good thing. Using the Gutenberg plugin is the intended way of accessing the upcoming features early.
  • Refactoring Gutenberg plugin APIs will be difficult once they get shipped with Core. In reality, that’s already the case.

If you see any other downsides, please speak out!

What alternatives have been considered?

  • Keep not acting on the problem.
  • Use the same Backwards Compatibility policy for both WordPress and the Gutenberg plugin – which would make both projects worse off.
  • Find a way to ship the experimental APIs with Core as “internal” and unavailable to plugin authors – which has been tried and did not get much traction.

Unfortunately, neither is viable, as explained in more detail in the GitHub discussion.

If this resonates with you, speak out before September 7th!

Policies don’t contribute to the Gutenberg plugin. People do. This proposal will only work if we, the contributors, believe it’s the right thing to do.

Please share your thoughts under this post or in the GitHub discussion – even if it’s just “I like it.” All opinions are welcome, especially if you are not convinced about this proposal.

This call for feedback will be open for the next two weeks until September 7th.

Props to Birgit Pauli-Haack (@bph), Grzegorz Ziółkowski (@gziolo), and Hector Prieto (@priethor) for their help in putting this proposal together.

#editor #gutenberg #core #proposal

Proposal: Disallow assignments in conditions and remove the Yoda condition requirement for PHP

After discussion with several coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers and WordPress leads, the title and the contents of the text were changed to clarify that this is a proposal and not a decision set in stone.

This proposal is the continuation of the long discussion on the WordPress Coding Standards (WPCS) repo.

Yoda conditions (or Yoda notation) is the programming style where the parts of an expression in the condition are reversed from the ‘typical’ order.

In a large part of the world, the natural reading order is left to right (LTR). This is what most programming languages adhere to. That means the variable assignments or echo/print statements are written with the variable first:

$post_type = 'post';

echo $post_type;

With the same idea in mind, conditions can also be written left to right, like:

if ( $post_type == 'post' ) {
    $category = get_the_category();
}

With Yoda conditions applied, the above condition would be written as:

if ( 'post' == $post_type ) {
    $category = get_the_category();
}

The idea behind it is that writing the value on the left side of the condition will prevent accidentally assigning the value to the variable since assignments can’t be made to values.

if ( $post_type = 'post' ) {
    $category = get_the_category();
}

While seemingly helpful at first glance, the obvious problem with them is the decreased readability of code, especially for people with reading disabilities such as dyslexia.

How we got here

When the handbook rule about Yoda conditions was introduced there was barely any static analysis tooling available in the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher world. The only ‘foolproof’ way to prevent accidental assignment in conditions was to invert the order of the value being checked and the variable.

Automated checking for assignments in conditions via PHP_CodeSniffer (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), the underlying tooling for WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards. May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook., became available in 2017. Moreover, the current sniffsniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. enforcing Yoda condition in the WPCS doesn’t protect against accidental assignments in conditions.

Today there is tooling in place that can help with identifying assignments in conditions, making the Yoda rules obsolete.

Keep in mind that strict comparisons (===) are already strongly encouraged and a part of the WordPress-Core ruleset (warning), making accidental assignments even less likely.

A thorough analysis was made by Lucas Bustamante in the WPCS ticketticket Created for both bug reports and feature development on the bug tracker. on the impact this could have on the plugins in the WordPress directory. The analysis showed that Yoda conditions are used in 18.02% of the plugins, so the majority of 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 are using non-Yoda conditions.

What to do next?

The discussion in the WPCS ticket is long and opinionated, but comes down to these points:

Disallow Yoda condition

  • Drop the handbook rule that requires Yoda conditions and instead explicitly disallow using them.

Remove Yoda condition as a requirement

  • Discourage, but don’t disallow Yoda conditions. Just don’t report if the code is or is not using Yoda conditions. The rule would also be dropped from the handbook.

In both cases, assignments in conditions will still be checked for and forbidden.

Impact on the Core code

Disallowing Yoda conditions for WordPress Core would mean that all existing patches on open tickets for Core would need to be revisited and fixed accordingly, which could burden the contributors.

Running the same analysis as Lucas did for plugins, over the WordPress Core, there were 5427 Yoda conditions, and 312 non-Yoda conditions.

Luckily, these are violations that can be automatically fixed using phpcbf tool, but care should be taken to check if all the violations were correctly fixed.

If Yoda conditions are discouraged (option 2), and the existing Yoda conditions in the Core code remain, that would mean less work for the 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., but also would add lots of inconsistencies in the Core code (mixed Yoda and non-Yoda conditions).

Next steps

The chosen way forward is to remove the Yoda condition as a requirement (remove it from the handbook) but not disallow it for the time being.

For WPCS, that would mean the removal of the Yoda conditions requirement (and sniff) in WPCS 3.0, with a notice that non-Yoda conditions will start to be required in WPCS 4.0 version.

Work is currently actively ongoing to prepare for the WPCS 3.0.0 release. There will be a minimum of six months between the 3.0.0 and the 4.0.0 release to allow time for Core and other projects to adjust.

Once WPCS 4.0.0 version is released, a one-time-only auto-fix of all the remaining Yoda conditions in Core will be made, and any patches to the Core which go in after that will have to use non-Yoda.

How to enforce the non-Yoda conditions in your code

If you are a WordPress plugin or theme developer, and you’d like to enforce non-Yoda conditions in your code, you can use the Generic.ControlStructures.DisallowYodaConditions sniff. In your phpcs.xml.dist file you should add the following sniff:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Example Project" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/squizlabs/PHP_CodeSniffer/master/phpcs.xsd">

    <!-- Your custom rules. -->

    <!-- Disallow Yoda conditions in your codebase. -->
    <rule ref="Generic.ControlStructures.DisallowYodaConditions"/>

</ruleset>

If you want to change the Yoda conditions to non-Yoda conditions, use the phpcbf tool (part of PHPCS) with the Slevomat coding standards. Specifically, the SlevomatCodingStandard.ControlStructures.DisallowYodaComparison sniff that has the fixer for the Yoda conditions.

Props to Juliette Reinders Folmer and Gary Jones for the proofreading and adding valuable feedback on the text. Also, a big props to Lucas Bustamante for the impact analysis on WordPress plugins.

#codingstandards, #php, #wpcs

Editor Chat Agenda: 10 August 2022

Facilitator and notetaker: @paaljoachim

This is the agenda for the weekly editor chat scheduled for Wednesday, August 10 2022, 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/..

Gutenberg 13.9 RC1 Released Wednesday 10th of August.
Thank you to @oandregal for handling the release!

Key project updates:

Task Coordination.

Open Floor – extended edition.

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

Dev Chat summary, August 3, 2022

@marybaum led the chat (transcript) on this agenda.

For more background, here’s the July 27 summary.

1. Welcome

To reiterate, if you come to devchat, that’s a compliment to the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team, and you are not only welcome but the main reason the chat runs when and where it does. In open-source development, every part of the software and its processes are for you. So do say hey with an emoji when you’re in the house!

2. Announcements

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/ 13.8 landed moments into the chat.

3. Blogblog (versus network, site) posts of note

A module proposal on GitHub.

A week in Core.

Moving Core block styling to theme.json.

Giving FSE a more user-friendly name.

An update on the new design for the .org home and download pages.

4. Upcoming releases

The next major is 6.1.

@costdev asked the group for tickets pending a formal 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.-scrub schedule. @presskopp suggested #16838, and a brief discussion followed.

The next minor is 6.0.2.

5. Open Floor

@hellofromtonya, asking for @zieladam, pointed the group’s attention to this proposal for a canonical HTML-processing API.

#core, #dev-chat, #summary

Performance team meeting summary 9 August 2022

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

Announcements

  • @shetheliving: Team Rep elections
    • We’ll follow the process previously used by the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team, outlined here
    • Bethany will add a nominations post to https://make.wordpress.org/performance/ this week

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: Working to complete several follow-up patches for WebP support. A couple of small fixes were committed last week, and the remaining patches are on track to land in the next week. The Pull Requests section at the top of https://core.trac.wordpress.org/ticket/55443 is a good way to check progress, since follow-up patches are boing worked on in PRs linked to this ticketticket Created for both bug reports and feature development on the bug tracker..
  • @mukeshpanchal27: Working on:
    • Core 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. follow-up – WebP compatibility: add fallback for non-supporting browsers to core – PR #3034 ready for review
    • Enhance JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. replacement mechanism for WebP to JPEG to more reliably replace full file name – Merged in 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
  • @erikyo: Noting that WebP conversion feature currently only works for JPGs, but in the future hope to also use PNG with Performance Lab and maybe a way to 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. the input format is needed
  • @adamsilverstein: If you used the mapping to create WebP from PNG uploads, the replacement code won’t work. We should be able to address, though our initial implementation is focused on JPEG > WebP. @erikyo will comment on the linked PR for further discussion.
  • @mehulkaklotar: Working on core patches for WebP uploads, ready for review: https://github.com/WordPress/wordpress-develop/pull/3030 and https://github.com/WordPress/wordpress-develop/pull/3048. Also working on https://core.trac.wordpress.org/ticket/45471 to allow caching of parse_blocks results.
  • @joegrainger: Working on plans for regenerate existing images module
  • @shetheliving: Should have a core feature proposal up for this in the next week

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @spacedmonkey out through 5 September
  • @tillkruess: Merged two PRs last week: https://github.com/wordPress/wordpress-develop/pull/2967 and https://github.com/WordPress/wordpress-develop/pull/2969
  • @pbearne: Not sure where the dominant color proposal is going, do we have the support to get it into core? Want to make sure it’s moving along
    • @flixos90 to review PRs this week, but welcome others too, as well: https://github.com/WordPress/wordpress-develop/pull/2907 https://github.com/WordPress/wordpress-develop/pull/2906
  • @itmapl: Interested in resolving https://core.trac.wordpress.org/ticket/32052; PR is here: https://github.com/WordPress/WordPress/pull/610. Open to comments on the solution so we can move forward.

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or 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.” 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/.
  • @shetheliving: Discussion in #326 Update Settings language for health checks. #423 about naming conventions; @olliejones will update the PR
  • @furi3r: Working on porting Site Health modules to core and there’s some new feedback in https://github.com/WordPress/wordpress-develop/pull/2890 and https://github.com/WordPress/wordpress-develop/pull/2894 which is raising some concerns:
    • Asking to move Object Cache Check to Async test. Should we do this on the plugin level first and then move it to core, or directly there?
      • @shetheliving: Thinking we should update in the plugin first, then port to the core PR once it’s merged; @flixos90 agrees
    • Use of custom filters, instead of using site_status_test_result filter.=
    • Asking to remove the color scheme we have used for alerts (green, yellow, green), and instead use same one for label (performance uses blue)
    • @adamsilverstein: Looks like valuable feedback on the PRs, suggest keep working there with @clorith and others to find a good solution
  • @olliejones: Still looking at the SQL database health checks. Pretty sure we can check for misconfigured/slow/ancient MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/./MariaDB, but none of this is actionable by a site owner. Do we want to proceed with health checks that aren’t actionable by “typical” users?
    • @shetheliving: Based on our discussion last week, seems like no – we want to focus on health checks that are actionable by typical (i.e. not developers, not ops people) users
  • @olliejones: Is there any way to move forward with MySQL optimization work in a way that can make it to core eventually?
    • Have a bunch of SQL server tests that say “ask your hosting provider to…” – should we abandon those?
      • @shetheliving: Those are okay because they provide an action that anyone can take, asking their hosting provider
      • @flashusb agrees
    • @zero4281: Does the Health Check module have hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. to add in additional more advanced health checks? If it did, Ollie could add those checks to his custom plugin
      • @flashusb: Yes, there is a hook to add custom checks, not a separate tab though
    • @furi3r: Agree we should expand Site Health use to more technical users, maybe a new tab? If we want to achieve bigger results, we shouldn’t limit ourselves
      • @ankitgade: Could be a separate tab, something like “Advanced Site Health Check”
    • @olliejones: Would be great to find a way to address these MySQL optimization issues, maybe the Woo team should address it?
    • @johnbillion: Did you move the MySQL optimization work to your plugin?
      • @olliejones: Yes, been in the plugin for over a year now. Can add custom health checks just like Yoast did.
      • @johnbillion: Think the best approach is to continue work in the plugin, including the health checks, and propose any changes that need to be made in core to facilitate them
      • @olliejones: There are possible core changes but they’re very difficult to pull off because many users are still stuck on MySQL 5.5
      • @johnbillion: Happy to review the plugin and help create performance benchmarks for the changes

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • @shetheliving: Reminder about the performance testing environment work started back in March: https://make.wordpress.org/core/2022/03/22/performance-team-meeting-summary-22-march-2022/. This has stalled out since then; if anyone is interested in picking it back up, let us know.

Feedback requested

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

  • @adamsilverstein: Resource preloading landed in https://core.trac.wordpress.org/ticket/42438. Some follow-up work for this work includes considering a more declarative 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. (currently it is implemented as a filter) and first party usage, e.g. applying preload to core resources in both wp-adminadmin (and super admin) and (core) themes

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Notable PR is https://github.com/WordPress/performance/pull/458, which enhances plugin uninstall to better support multisite. Next Performance Lab 1.4.0 will be released on Monday; please finalize any PRs by tomorrow.

Feedback requested

Open Floor

  • @shetheliving: I’ll be offline on medical leave August 22 through September 9; please ping @flixos90 or @mukesh27 during that time if you need help with anything
  • @alaca: SVG uploads
    • @alaca: Would like to discuss possible approaches. The idea to allow only static XML files for now is great, but I think we can do more – which depends on the approach we want to take when detecting the dynamic file. Two possible approaches:
      • 1) We have a list of keywords that shouldn’t be in the document, we can just check that, and prevent document upload if we find something inside the document
      • 2) Parse the document to see what’s in there, but then we have an opportunity to do more, such as sanitization.
    • @alaca: Each one of the third party solutions out there is using the same library for SVG sanitization; it’s great and battle tested. Want to use the same approach and simplify the implementation a bit with one simple class.
    • @olliejones: Are there exploit vulnerabilities stemming from parsing XML?
    • @masteradhoc: Want to be able to upload any SVGs that I have and have WP sanitize them for me if there’s an issue
    • @erikyo: I use a completely different approach in https://github.com/erikyo/OH-MY-SVG; they aren’t stored in the Media Library, but there are advantages like being able to edit them
    • @masteradhoc: Think not having them in the Media Library would be confusing
    • @erikyo: If they’re stored in the Media Library they can be processed by ImageMagick

Our next chat will be held on Tuesday, August 16, 2022 at 11am EDT in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

Bug Scrub Schedule for 6.1

With 6.1 well underway, here’s the initial schedule of 6.1 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. scrub sessions. These 6.1-specific ticketticket Created for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.

Alpha Scrubs:

Hosted by @audrasjb:

Hosted by @chaion07:

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. Scrubs:

Focus: issues reported from the previous beta.

RCrelease 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). Scrubs:

Focus: issues reported from the previous RC

  • TBD

Check this schedule often, as it will change to reflect the latest information.

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

The above 6.1 scheduled bug scrubs are separate and in addition.

For your reference, here are some of the recurring sessions:

Have a recurring component scrub or triage session?
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.” @audrasjb or @chaion07 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/. to have it added to this page.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at anytime? Yes, you can!

How? Ping @audrasjb or @chaion07 on slack and let us know the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 6.1-focused? Awesome! It can be added to the schedule above. You’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub?

  • Report 5 provides a list of all open 6.1 tickets:
    • Use this list to focus on highest priority tickets first.
    • Use this list to focus on tickets that haven’t received love in a while.
  • Report 6 provides a list of open 6.1 tickets ordered by workflow.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to @audrasjb or @chaion07 on slack.

#bug-scrub

[Request for feedback] Feature Notifications Proof of Concept

The goal of the WP Feature Notifications project is to create a new and better way to manage and deliver notifications to the relevant audience. The admin_notices hook has served WordPress well and will continue to do so for the foreseeable future. This project is focused on building a new framework for notifications from the ground up, and potentially providing a tool that encourages consistency in presentation, follows best practices in standards and accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), and discourages spammy or disruptive interactions in the WordPress adminadmin (and super admin) screens.

The end result will be a RESTful model and 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. to be utilized by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. but would also enable third-party developers to further extend the functionality. Possibilities could range from pulling in updates from relevant SaaS integrations and hosting platforms, to enabling mobile push or 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/. notifications outward from your WordPress website.

After approximately three years of discussion, scaffolding, and design, the WordPress Notifications feature project is ready to begin collecting feedback on a static demo of the previously reviewed designs. We’re inviting users to install the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. on a test environment, view the static mockups, and provide feedback to the team. 

How To Install

The 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 zip file can be downloaded from the Releases page of the Github repository, and installed like any other WordPress plugin.

Alternatively, it can be installed via Composer:

First add the repository to your composer.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.

{
    "type": "vcs",
    "url": "https://github.com/WordPress/wp-feature-notifications"
}

Then install the develop 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". using the command composer require wordpress/wp-feature-notifications:dev-develop.

How To Test

Once installed and activated, the plugin will display three demo user interface elements for review:

  1. On-page notifications – Similar to the current admin_notices hook, on-page notifications appear at the top of the Dashboard screen.
  2. The Hub – A new “bell” notifications icon on the right-hand side of the admin bar will open the “hub”, a drawer of notifications.
  3. Notification Settings – Users can visit Settings > Notifications or click the link at the bottom of the Hub to see a preliminary draft of a settings table for managing notifications.

It is important to note that this is a static, front-end demo, and the team is mainly looking for overall feedback about the initial direction of these components. For more context on the project, we recommend reviewing the Project Requirements and reviewing the initial Project designs

Looking Ahead

We look forward to collecting your feedback in the comments below or in our Github issues. If you would like to contribute to the project, we invite you to join the #feature-notifications channel in the Making WordPress Slack for our weekly office hours every Wednesday at 14:00 UTC and are happy to welcome new contributors to the project.

Props @psykro for editing and proofreading and @codekraft and @sephsekla for providing content.

#feature-notifications

Giving FSE a More User Friendly Name

tl;dr: The terms “full site editing” and “full site editor” (also abbreviated as FSE) were developed to easily refer to a collection of features and now that those features are integrated into our daily WordPress experience, how can we best update the wording to be more user friendly?

Not sure the difference between 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/, full site editing, and other terms here? Check out this post for high level definitions.

What I know

Many years ago when we started referring to some of the work going into Gutenberg’s Customization phase (Phase 2) as “full site editing” it was meant to differentiate from the work that had come out of Phase 1. Phase 1’s work was focused on bringing blocks to posts and much of the page surrounding posts, but Phase 2 was meant to move those blocks to the rest of the site editing experience—hence “full site editing”.

There are some issues with the term “full site editing”, though.

  • It was already possible to edit every part of a WordPress site using code. The term “full site editing” differentiated between phases of a project, rather than a new capability in the CMS.
  • To us, “full site editing” implies the use of blocks, but for new users there’s no reason for them to expect anything else. The term isn’t descriptive of what makes it unique.

As we continue the move toward a full-featured, true WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience for WordPressers of all skill levels, we should have a way to refer to it that is immediately meaningful for new users of our software, while also being an easy to reference term for all of us building and supporting the software.

What I see 

There are a few existing conversations around renaming Full Site Editing (both from a UIUI User interface/UXUX User experience perspective as well as a development perspective). From what I have seen in my reading, there are two primary contexts from a big picture perspective: Users & Visitors of WordPress; Contributors & Extenders of WordPress. That leads me to think we have two primary use cases for terms as well.

  • Users & Visitors of WordPress: I’ve heard a lot of people outside of the WordPress ecosystem simply referring to this as “the WordPress editor”. That seems mostly applicable to folks building with WordPress, selling on WordPress, or otherwise not creating the CMS itself.
  • Contributors & Extenders of WordPress: I have primarily seen references to “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” with the understanding that work toward Full Site Editing is a suite of tools from within the Block editor, a framework that originated in the Post Editor but is extending to all areas of WordPress like the Site Editor, hence most editing interfaces evolving into “the Block Editor”. This seems mostly applicable to folks working in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., on Themes/Plugins, and by extension, also Training, Design, and Documentation.

What other contexts do you think we need to be aware of as we look toward making this more user friendly?

What I need

As with any audacious journey, one of the things that will hinder our success is not knowing what stands in our way. I would love it if you’d share your thoughts on the following questions!

  1. We’ve referred to it this way for a long time. How can we tackle renaming this together?
  2. It’s in the codebase. How will we make sure people who aren’t regular contributors see this?
  3. And repeating the in-line question from above: What other contexts do you think we need to be aware of as we look toward how to refer to our collective work in the future?

#core-editor, #editor, #gutenberg