Proposal: cancel core editor chat

Proposal: cancel coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor chat

The core editor chat is a 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/. meeting that takes place every week on Wednesdays in the core-editor channel of the WordPress Slack instance, focused on discussing topics related to 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/ 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 development.

This meeting has served in time as a place for the following types of communication:

  • general announcements about Gutenberg or WordPress
  • Gutenberg project updates, on various features in development
  • task coordination between the various people contributing
  • community introductions and help during open floor
  • issue escalation – bringing attention to specific issues
  • requests for help or reviews, a place to ask for an extra pair of hands or eyes

The meeting has served us well over the years, but in the past two years several developments occurred:

  • the post pandemic speed of people picking up these meetings was suboptimal
  • the GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ project management has been considerably better
    • there are people managing tracking and overview issues, updating them with project status
    • the project features of GitHub itself have been significantly upgraded
  • several other efforts picked up steam:
    • there is a new learn section on 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/
    • there is a revamped developer blogblog (versus network, site) on wordpress.org
    • developer experience and outreach programs improved
    • we have a constant stream of events like hallway hangouts on varied topics

Considering the above, I suggest that the meeting has now become an inefficient use of the time for those organizing it. 

It’s not only that the attendance is low, but the topics discussed and the lack of interest in the meeting itself point to the fact that the other avenues are doing a better job at keeping people engaged and updated with the progress of Gutenberg in WordPress, as well as providing much better avenues for getting support to contribute to or implement the core editor.

Therefore we propose discontinuing the meeting.


What do you think? You’re all invited to chime in with pros and cons, ideas and anything related for the duration of a three week comment time for this proposal to cancel the core editor chat for an indeterminate duration of time.


Thank you

Many thanks to the following list of people who have been helping across the years with running, summarizing and managing the agenda of the core editor chat:

@ajitbohra @annezazu @paaljoachim @fabiankaegy @jorgefilipecosta @get_dave @zieladam @bph

Important note

For the duration of the comment time (three weeks) there will be no more core editor chats (meetings).

#chats, #editor-chat, #proposal

Experimental APIs in WordPress Core have largely been tamed

Last year’s proposal to stop merging experimental APIs from Gutenberg to WordPress Core is now mostly implemented.

To recap: Due to 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/. technical limitations, the recurring merge of 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 WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. led to a premature release of many experimental APIs.

After a long discussion and discovery process, Gutenberg introduced a distinction between Plugin-only APIs and Private APIs.

Plugin-only APIs 

Plugin-only APIs are like early access feature previews that require community feedback to mature. They are only released as a part of the Gutenberg plugin and not merged into WordPress core. It’s implemented as follows:

// Using IS_GUTENBERG_PLUGIN allows Webpack to exclude this
// export from WordPress core:
if ( process.env.IS_GUTENBERG_PLUGIN ) {
  export { pluginOnlyAPI } from './api';
}

Private APIs 

Private APIs are internal. They are merged into WordPress core, but cannot be accessed by extenders in plugins or themes. Only the code inside 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 can access the private APIs using the dedicated utilities – please review the coding guidelines to find out more.

Aftermath 

The goal of taming new experimental APIs has largely been achieved. Thanks to the recent coordinated effort to use the private APIs, only two new ones made it into WordPress 6.2. In contrast, previous WordPress releases introduced 14, 20, and even 40 new experimental APIs. Two is phenomenal 🎉 The remaining follow-up work is being tracked separately in GitHub issue #47786

Regarding the stabilization of the existing experimental APIs, a case-by-case assessment of the several hundred experimental APIs in WordPress core will be necessary. WordPress 6.2 addressed a few such exports, and the rest will likely be gradually addressed in future releases. Some may get stabilized, others may get deprecated, and others may stay indefinitely. The upcoming WordPress Community Summit may provide some answers, as the issue of deprecating JavaScript APIs has been proposed as a discussion topic.

Many thanks to everyone for the productive discussions and efforts. The outcome of this effort is a testament to the commitment of the WordPress community to maintain high-quality software.

Props to the following editors and reviewers of this post: @gziolo @ndiego @cbringmann @mcsf @akirk @peterwilsoncc @priethor

#core, #gutenberg, #proposal

Proposal: Updates to the WordPress Release Cycle

What is Feature Freeze

In the WordPress release cycle, feature freeze happens when the first 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. version is released. “Feature freeze” means that development of new features and enhancements ends, and work continues on testing them and fixing bugs. They have to be ready for testing and committed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. before the freeze, before Beta 1 is released.

Exceptions to Feature Freeze

Changing tickets from “enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.” to “task” right before Beta 1 is an exception that has been used for many years. It was strictly for new features and substantial enhancements that weren’t ready in time for beta, and needed a few more days to get completed and committed (thus delaying their testing to Beta 2). The intent was to allow another two or three days, not a week or two. This exception used to happen quite rarely, perhaps a few times per year.

However lately this exception has become part of the standard release workflow. In recent years, it’s become common for 15 to 20 tickets for code coming from 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/ to be changed to tasks each release. The reason they are changed is not to give the developers a few more days to complete them. It is mostly to signify that they are going to be committed later.

Why Gutenberg Merges Are Different

The new features and enhancements coming from Gutenberg have already been tested. I think everybody would agree that testing in Gutenberg releases is quite better and more efficient than testing in core trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. beta releases:

  • The Gutenberg plugin is used on over 300,000 sites, including some huge sites like WordPress.com.
  • According to recent stats at least 60% of these sites are rapidly updated to the newest version of 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.

So the new features and enhancements that are in a Gutenberg release are being tested on at least 180,000 sites, and by well over 180,000 users, mostly in a production environment. For comparison, there are usually only a few thousand installs for beta releases.

It seems the WordPress release workflow should adapt to these changes in the development process: synchronizing code between two repositories, new Gutenberg releases every two weeks, etc. Using the old “change enhancements to tasks” exception shouldn’t be necessary for code that has already been released and tested in Gutenberg. However, it still makes sense for feature development that happens on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

New Ticketticket Created for both bug reports and feature development on the bug tracker. Type: Gutenberg merge

I’d like to propose to stop changing tickets from “enhancement” to “task” before beta when the code has been sufficiently tested in Gutenberg.

Based on the above plugin installation stats it seems that a sufficient time for testing in a Gutenberg release would be one week. Ideally, all code coming from Gutenberg would meet this criteria, regardless of the WordPress release cycle stage (alpha, beta, or 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).). An exception would be when committing 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. fixes that can be tested simultaneously in Gutenberg and core beta/RC releases.

To easily distinguish these tickets maybe a new ticket type can be introduced. Perhaps “Gutenberg merge” or “Gutenberg sync”? Alternatively, the existing gutenberg-merge keyword could be used, although it would be somewhat less noticeable.

For example:

Feedback

I realize that this proposal affects only a small part of the community, primarily frequent 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., committers, and release leads. But I still think it is best to propose it here in the interest of openness, and for documentation purposes.

If you have thoughts about how new Gutenberg features are handled with regard to “feature freeze” during the beta stage of the release cycle, please share them in the comments below.

Thanks @peterwilsoncc, and @ironprogrammer for the review and suggestions.

#proposal, #release-process

Enhancing the Scripts API with a loading strategy

Overview

This post outlines a proposal to add a script loading strategy enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s existing Scripts 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..  

The underlying goal of this effort is to make it easier for WordPress 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 and theme developers and core to use “modern” loading approaches for 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/. (like defer and async), which will help WordPress sites load faster and operate more smoothly, giving users a better experience.

Why add a loading strategy?

Data from the Web Almanac project (query) indicates that render blocking JavaScript is a significant problem on the web, with 77% of mobile pages having render-blocking scripts in the document <head> . This query shows that approximately 40% of WordPress sites stand to benefit from deferring additional scripts. Adding defer or async to script tags enables script loading without “blocking” the rest of the page load, resulting in more responsive sites overall better user experience.

Currently WordPress core as well as plugins and themes register scripts with the wp_enqueue_script and/or wp_register_script functions. Although these functions include the ability to control the placement of the script (with the in_footer parameter), they don’t include support for adding modern attributes such as defer or async to script tags. 

To add async or defer today, developers must resort to less flexible and more fragile approaches, such as directly filtering the tags at the point of output (using  the script_loader_tag 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.), or handling the tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) output directly using wp_print_script_tag and the wp_script_attributes filter.

Using the first approach and directly filtering the tag can easily break: for example if two plugins both try to filter a tag, or if a tag has unexpected attributes already (eg. adding defer to a tag that already has async). Using the the second approach developers must carefully handle dependencies and output manually – things that that the Scripts API usually helps take care of.

How the loading strategy works

Developers specify a loading strategy when registering or enqueueing a script. For example, a defer strategy can be specified when the script isn’t required immediately during the page load cycle. WordPress will then determine which scripts can actually use a strategy based on logic for each strategy. For example, to ensure that scripts are executed in the order they are enqueued, defer can only be used on a script if every script that depends on that script can also be deferred. Inline script tags added with wp_add_inline_script would also be considered to ensure proper execution order.

The implementation would come with several initial built-in loading strategies: defer, async, and the default blocking behavior.

Out of scope for this feature

The loading strategy does not enable direct control of script tag attributes. This idea was originally proposed 10 years ago in #22249 and several approaches were considered on that ticketticket Created for both bug reports and feature development on the bug tracker. including a script attribute filter. This proposal takes a step back and aims to solve the script loading strategy aspect more comprehensively and directly while avoiding exposing the potential complications of direct attribute control.

It is worth noting that it is already possible to control attributes on wp_enqueue_script tags directly using the script_loader_tag filter. However, this is a bit of a “brute force” approach which is limited and fragile because it doesn’t consider dependencies and multiple plugins can take conflicting actions on the same tag. 

What are potential concerns with this feature?

One big concern with adding this feature to the WordPress Script API is potentially introducing a breaking change. wp_enqueue_script is a fundamental API in WordPress core, and any breaking changes could have widespread implications. Possible breakage is a possible reason that adding custom attributes as proposed in #22249 was never added to core.

This new proposal aims to ensure that there is 100% backwards compatibility, resulting in zero risk of breakage. The loading strategy will ensure that all existing uses continue to function as expected; for example, passing the boolean in_footer attribute will still control script placement. In addition, it will ensure that scripts continue to be executed in the order they are enqueued – as described above in the “How the loading strategy works” section.

Conclusion and Next Steps

Giving developers the ability to specify a loading strategy will enable them to use more advanced JavaScript loading methods while still ensuring that enqueued scripts are executed in the correct order. A “strategy” approach is also forward thinking: as the web evolves, new strategies can be developed and made available to WordPress developers. After gathering feedback, we will proceed to discussing the implementation approach and, ultimately, proposing a 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..

Have you tried using defer or async with WordPress (or do you already)? How do you think this enhancement would change that? Please leave your feedback about this proposal in the comments below and if you can, join us at our weekly performance team chats, where we are likely to discuss this proposal in the future.

Thanks to @flixos90, @tweetythierry and @mxbclang for help writing and reviewing this post and for the many contributors who have added to the discussion around this enhancement already.

#core, #feature-projects, #javascript, #performance, #proposal

Proposal: Amend the Inline Documentation Standards for multi-line comments

This is a small proposal to amend the standards for multi-line comments. The current standards seem to require that multi-line comments have to be done like this:

/*
 * This is a comment that is long enough to warrant being stretched over
 * the span of multiple lines. You'll notice this follows basically
 * the same format as the PHPDoc wrapping and comment block style.
 */

There is also a warning that they must not begin with /** as that is the DocBlockdocblock (phpdoc, xref, inline docs) syntax, and may result in parsing errors.

The proposal is to remove this requirement and to encourage multi-line comments to be done with slashes, same as single-line comments.

// This is a comment that is long enough to warrant being stretched over
// the span of multiple lines. You'll notice this follows basically
// the same format as the single-line comment style.

Reasons:

  • Reduce possibility of typos and eventual parsing errors. This is not just from typing, seems many modern IDEs can auto-complete or auto-correct /* to /** which may lead to more typos.
  • The de-facto 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/. coding standard Prettier, and the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher’s PSR-12 do not enforce specific comment styles.
  • In addition to encouraging typos, the current standard is visually very close to the DocBlock standard which may lead to a moment of confusion when reading the code (uh, is this an incomplete DocBlock that doesn’t have @since and @param?).

#proposal

Client-side WebAssembly WordPress with no server

This early demo runs a full WordPress directly in the browser without a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher server! While it isn’t fully stable yet, it is a major breakthrough that could transform learning, contributing, and using WordPress. This post explores the opportunities and explains in detail how it works. 

Your help is needed to realize the vision laid out below. None of the presented mockups and early explorations are currently reliably implemented. This project needs volunteers to stabilize the code and build revolutionary tools on top of it. If you’d like to be a part of it, please say so in the comments!

Learning WordPress in the browser

The code examples in the WordPress handbook could become runeditable, like in this early preview:

Furthermore, an in-browser IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. could lead new contributors through solving their first “Good first issue” without setting up a local development environment. Just like this early preview:

Finally, a guided code editor could become a primary teaching tool for new developers. They would click a “Build your first 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.” button on 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/ and immediately start coding. This is what it could look like:

WordPress Developer tools

Testing code on different WordPress, PHP, and 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/ versions currently require a tedious setup. With an in-browser WordPress IDE, it wouldn’t require any setup at all. As a developer, you would switch between the different versions by selecting different entries in a box:

Taking it further, the continuous integration pipeline could replay the failed tests right in the browser and provide a code editor to debug and fix the problem on the spot:

On a different note, the desktop and mobile apps could reuse WordPress code by running an actual WordPress instance – even when offline.

Finally, WordPress could potentially be scaled up by spinning up many tiny self-contained WASM instances directly on the edge servers.

Showcasing

Embedding a demo of your 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, pattern, or theme directly on the website makes another great use case. One such demo lives on wpreadme.com, an in-browser WordPress readme.txt editor. Here’s what the plugin directory could look like:

Today, a WordPress server is required, and ideally, one WordPress per user to always present the same initial state.

The in-browser WordPress enables one private WordPress per user with no marginal server cost. Everyone can start logged-in as an adminadmin (and super admin) with no security risks.

Furthermore, importing an existing WordPress website into WASM runtime would create a staging website. Users could try themes and plugins on a copy of their site without affecting the live sites. Then, once the staging website looks good, they’d click a button and publish the changes.

How else would you use the in-browser WordPress? Please share your ideas in the comments so more use cases can be considered in the future.

How does the in-browser WordPress work?

The code lives in the GitHub repository.

In short:

  • PHP is compiled to WASM with Emscripten
  • WordPress is packaged into a data bundle
  • A service worker traps HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. requests and re-routes them to WordPress.

See more details below.

PHP is compiled to WASM with Emscripten

Firstly, PHP is compiled using an adjusted recipe from the php-wasm repo. It’s powered by Emscripten, a drop-in replacement for the C compiler. Unfortunately, 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/. currently cannot run as WASM. However, SQLite can, and WordPress supports SQLite via the wp-db-sqlite plugin.

Emscripten compilation yields two files: webworker-php.wasm, which is the assembly, and webworker-php.js, which downloads the assembly file, creates a virtual heap, and exposes named native functions conveniently wrapped to accept and return 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/. data types.

You need to load the webworker-php.js in a webworker and add a tiny wrapper class:

const php = new PHPWrapper();
console.log(
    await php.run(`<?php echo "Hello world";`).stdout
);
// "Hello world"

See the Dockerfile, the compilation script, and the php-wasm playground.

WordPress is packaged into a data bundle

WebAssembly PHP runtime has its own filesystem and WordPress is shoehorned into it as a data bundle.

First, a fresh WordPress distribution is downloaded and patched with the wp-db-sqlite plugin. It’s about 66MB large, but an optimization pipeline makes that 46MB by minifying the PHP files and removing non-essential static assets. Getting down to just 12MB is possible, but it’s not easy.

Second, the WordPress installation process kicks in. A script serves our WordPress via the built-in PHP server and sends a special curl request to /wp-admin/install.php?step=2. Unfortunately, wp-cliWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ is hard-wired to MySQL and not a good match here.

Lastly, Emscripten’s file_packager turns our WordPress copy into a data file named wp.data and a JavaScript loader named wp.js. Loading both the PHP runtime from webworker-php.js and the WordPress data bundle from wp.js allows you to run <?php require “wordpress/index.php”; right in the browser!

A service worker reroutes the HTTP to WordPress

WordPress reads request information from $_SERVER, $_GET, $_COOKIE and so on. Normally these variables are populated by ApacheApache Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free., NginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/., or another web server. However, in this case, there isn’t one.

Instead, the superglobal variables are populated “manually”:

function request(path, method, body, cookies) {
    return php.run(`<?php
        $_POST   = json_parse('${JSON.stringify(body)}');
        $_COOKIE = json_parse('${JSON.stringify(cookies)}');
        $_SERVER['REQUEST_URI'] 	= $path;
        $_SERVER['REQUEST_METHOD']  = "${method}";
        require "wordpress/index.php";
    `);
}

That takes care of the request, but capturing the complete HTTP response is still necessary. The PHP outputs information in only two ways: stdout and stderr. The response body comes out via stdout, but the HTTP status code and headers don’t. They need to be manually streamed to stderr where the JavaScript app can capture them:

register_shutdown_function(function() use() {
    $stdErr = fopen('php://stderr', 'w');
    fwrite($stdErr, json_encode(['status_code', http_response_code()]) . "\n");
    fwrite($stdErr, json_encode(['session_id', session_id()]) . "\n");
    fwrite($stdErr, json_encode(['headers', headers_list()]) . "\n");
}

The final request handler is similar to this:

function request(path, method, body, cookies) {
    const { stdout, stderr, exitCode } = php.run(`<?php
        $_POST   = json_parse('${JSON.stringify(body)}');
        // ... Populate other superglobals...
 
        register_shutdown_function(function() use() {
            $stdErr = fopen('php://stderr', 'w');
            fwrite($stdErr, json_encode(['status_code', http_response_code()]) . "\n");
            // Output other information
        }
 
        require "wordpress/index.php";
    `);
 
    const { statusCode, headers, body } =
        rawOutputToResponse({ stdout, stderr, exitCode });
    return { statusCode, headers, body };
}

The actual code is much more involved, but it’s based on the same idea.

Node.js is supported, too

Running WordPress in different JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. runtimes is a matter of connecting these major building blocks with runtime-specific plumbing. Today there is an in-browser version and a node.js version. Here’s how they differ:

In-browser version

WordPress is rendered in an 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. by a minimal index.htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. once both workers are loaded.

Node.js version

  • Emscripten compiles PHP for the Node.js runtime.
  • A Node.js script loads the WebAssembly PHP and mounts a local WordPress directory inside the PHP filesystem.
  • The same Node.js script starts a web server. It serves most requests as static files, except the .php ones, which it routes to WordPress.

WordPress is served on localhost:8888.

Running an in-browser WordPress IDE with Stackblitz

Stackblitz is the in-browser IDE that makes Svelte docs interactive:

It could do the same for WordPress docs; see this early preview.


Stackblitz doesn’t need a specialized backend. It runs Node.js, npm, and webpack right in the browser via WebAssembly. Other than hosting and delivering a few megabytes of data, Stackblitz has no marginal costs. This idea is called Web Containers.

Learning WordPress and writing code used to be separated. Now they can be one and the same. From runnable code snippets to new, svelte-like docs formats, WebContainers + WebAssembly WordPress is an educational game-changer.

WordPress runs in Stackblitz via a Node.js server

The minimal WordPress plugin dev setup on Stackblitz consists of:

  • A node.js WordPress server (via an npm package)
  • A plugin directory mounted inside of mu-plugins
  • A wp-scripts setup to watch and bundle the JavaScript files

@gziolo went a step further and prepared a version with an editable Gutenberg block generated via create-block. All it took was running the npx @wordpress/create-block example-static command as shown in the create-block documentation, and restarting the dev server with npm run start:

However, a Node.js WordPress server on Stackblitz is sluggish

Rendering a single wp-admin page takes a second locally but up to 40 seconds on Stackblitz. That’s much longer than most developers are willing to wait. Here’s why that happens:

A local Node.js WordPress server works like this:

  • WordPress runs on WebAssembly PHP
  • WebAssembly PHP runs on a native Node.js

However, a Stackblitz Node.js WordPress server has an extra layer:

  • WordPress runs on WebAssembly PHP
  • WebAssembly PHP runs on WebAssembly Node.js
  • WebAssembly Node.js runs on a native Chrome

It’s like a box in a box: A WebAssembly runtime in Chrome runs Node.js that has its own WebAssembly runtime. WordPress runs on the latter, not on the former, and that indirection causes a massive slowdown.

Luckily, the browser can run WebAssembly natively without an intermediate Node.js layer.

An in-browser WASM WordPress is really fast

Here’s a Stackblitz WordPress setup using the webworker WordPress version:

It is much faster! Unfortunately, the speed comes at the expense of simplicity.

Stackblitz requires a service worker just like the in-browser WASM WordPress. However, you can only have one per domain. Therefore, the WordPress files in this example are hosted on a Netlify domain.

Then, the Stackblitz files can’t be directly mounted into the in-browser PHP filesystem. The changes need to be synchronized manually. In this example, a node.js file watcher notifies the PHP webworker about the updates via WebSockets and onmessage/postMessage. There are bugs, but all are fixable.

Known issues

WASM WordPress issues:

  • The in-browser WordPress builds sometimes crash the Chrome tab, see the GitHub issue. Firefox, Safari, and node.js are much more stable.

Stackblitz integration issues:

  • The in-browser Stackblitz setup doesn’t watch subdirectories.
  • WordPress exceeds Stackblitz size limits unless imported as a node_module.
  • Stackblitz corrupts a predefined binary .sqlite database file. A base64-encoded version is shipped instead.
  • Stackblitz doesn’t pass a server-side set-cookie headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. to the browser. That’s a 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.. Workaround: the express.js server handles the cookies internally.

Next steps

Your help is needed to fully realize the vision laid above. None of the presented mockups and early explorations is currently reliably implemented. This project needs contributors to stabilize the code and build revolutionary tools on top of it – see the issues list on GitHub. If you’d like to be a part of it, please say so in the comments!

Resources

Props to @bph, @annezazu, and @gziolo for their thorough help with reviewing and editing this post.

#core, #editor, #proposal

A new system for simply and reliably updating HTML attributes

This call for feedback will be open until September 9th.

Let’s introduce a reliable tool WordPress could use to adjust the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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. markup. The current practice of using basic replacements seems fine at a first glance but is easy to break. The system proposed here will help avoid these common pitfalls.

Consider this example of adding a style HTML attribute in the cover block:

preg_replace( '/class=\".*?\"/', '${0} style="' . $styles . '"', $html );

It assumes a specific HTML structure:

  • There is a class attribute
  • The style attribute isn’t already defined, as browsers ignore the repeated attributes.
  • There is no other attribute ending with the string class="", such as data-replace-class="…" or title='how to set the class="" attribute'
  • The existing class attribute uses double quotes and no single quotes or no quotes.
  • Regular HTML does not contain the class="" substring, for example in a post describing how to use the class attribute in an HTML document.

These assumptions are typically true, but only until they’re not. For example, applying a padding produces a markup such as below where the browsers ignore the second style attribute:

<!-- Formatting applied for clarity -->
<div
    class="wp-block-cover"
    style="background-image:url(/img.png);"
    style="padding-top:4px">

The original preg_replace could be patched, but eventually another assumption would break. The deeper, fundamental problem is that string replacements are not the right tool for updating HTML. They’re used out of necessity as WordPress does not provide any better tools. Well, let’s change it!

Let’s introduce a dedicated tool for reliably updating the HTML markup. It’s called WP_HTML_Walker:

$w = new WP_HTML_Walker( '<div></div>' );
$w->next_tag();
$w->set_attribute( 'style', $styles );
$updated_html = (string) $w
// <div style="display: block"></div>

Simple string replacements don’t account for nuances in HTML

The problem of updating HTML attributes frequently appears in block-related work. Recently @dmsnell and I (@zieladam) investigated how HTML attributes are typically updated in the WordPress codebase while exploring adding a CSS class to all Gutenberg blocks. We found the typical approach is to use string replacements similar to the one covered above.

Here are a few examples already in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. where we run into these nuanced problems:

The Site Logo block attempts to remove the href attribute:

// Remove the link.
preg_replace( '#<a.*?>(.*?)</a>#i', '\1', $custom_logo );

However, it also unintentionally removes all the attributes, including class and style.

The gallery block adds a CSSCSS Cascading Style Sheets. class:

preg_replace('/' . preg_quote( 'class="', '/' ) . '/', 'class="' . $class . ' ', $content, 1);

However, if there’s no existing class attribute, it will skip over the tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) without adding the required class. The same technique is used in the duotone feature, and the block supports API.

As a side note, it’s easy to lean on the existing pattern of using more complicated functions such as preg_replace(). Calling preg_quote() in this example isn’t appropriate and the entire regular expression pattern does nothing more than a basic str_replace().

The block-supports 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. attempts to find the first HTML tag:

preg_match( '/<[^>]+>/', $block_content, $html_element_matches, PREG_OFFSET_CAPTURE );

However, it also matches non-tags like text hearts and mathematical expressions (<3, f(x) = {x, x<5; -1, x>=5}), DOCTYPE declarations, and HTML comments.

The media library adds the srcset attribute:

preg_replace( '/<img ([^>]+?)[\/ ]*>/', '<img $1' . $attr . ' />', $image );

However, a > character inside a tag attribute (e.g. title="why tacos > burritos")  would break the srcset functionality and potentially introduce a vector for injection attacks.

The list goes on, and it’s not just blocks.

Here’s an example from shortcodes:

if ( preg_match( '#((?:<a [^>]+>\s*)?<img [^>]+>(?:\s*</a>)?)(.*)#is', $content, $matches ) ) {

Media Embeds:

if ( preg_match_all( '#<(?P<tag>' . $tags . ')[^<]*?(?:>[\s\S]*?<\/(?P=tag)>|\s*\/>)#', $content, $matches ) ) {

Media Galleries:

preg_match_all( '#src=([\'"])(.+?)\1#is', $gallery, $src, PREG_SET_ORDER );

Twentynineteen:

preg_replace( '/<a\s.*?>/', $link, $item_output, 1 );

And many, many other places. The point is, this is how WordPress does it today.

Many features demand a more reliable way of updating HTML attributes. Block theming code, in particular, tends to modify block markup to apply visual styling:

The only way to reliably update HTML attributes is to follow the HTML specification. However, doing that from scratch every time a CSS class is added would only cloud the entire codebase with HTML parsing nuances and distract from the work being done. That’s why @dmsnell, @gziolo, and I (@zieladam) want to move this complexity into Core. It would be exposed as a tailored and restricted API that’s easy to use, hard to mess up, and easy to find.

The new system tokenizes HTML

WP_HTML_Walker (Pull Request 43268) recognizes HTML tags and updates their attributes. It’s reliable because it implements the same official HTML specification as WebKit, Chrome, Firefox, and other major browser engines.

Unlike full-fledged HTML parsers, the walker avoids handling malformed markup, semantic problems, and building a document tree. Any problems that are present on the input are passed on to the browser. The walker doesn’t fix HTML just as it won’t break HTML.

The tradeoff is that it only offers a simplified API to modify HTML attributes. If you want to replace an img tag with a full-fledged figure layout, this API won’t offer that functionality. Similarly, the walker won’t help you replace all the child nodes of a particular div with a completely new markup. This system is focused on finding specific HTML tags and adding, removing, or updating the attributes on those tags.

Remove the href attribute from an anchor tag:

$w = new WP_HTML_Walker( $html );
$w->next_tag( 'a' );
$w->remove_attribute( 'href' );

Add a style attribute to the first tag in the document:

$w = new WP_HTML_Walker( $html );
$w->next_tag();
$w->set_attribute( 'style', 'display: none' );

Add a CSS class to the first tag having the wp-block-media-text__content class:

$w = new WP_HTML_Walker( $html );
$w->next_tag(array(
    'class_name' => 'wp-block-media-text__content'
));
$w->add_class( 'wp-foo-bar' );

Add the srcset attribute to all image tags:

$w = new WP_HTML_Walker( $html );
while ( $w->next_tag() ) {
    if (
        isset( $w->get_attribute( 'src' ) ) &&
        ! isset( $w->get_attribute( 'srcset' )
    ) {
        $srcset = build_srcset( $w->get_attribute( 'src' ) );
        $w->set_attribute( 'srcset', $srcset );
    }
}

Processing HTML using this Core API could help avoid a broad array of mistakes that appear due to the oversimplification presented by the array of ad-hoc solutions. A common interface for operations on block markup would alleviate competition between changes. You can check the refactoring PR to see how this new API could improve code readability in the existing core blocks.

Why build a new API instead of using DOMDocument?

Using DOMDocument was extensively discussed. It’s not installed on every host so a polyfill would still be necessary. And even if it was available everywhere, it’s based on libxml2 designed to parse XML. Libxml2 does not implement the WHATWG HTML parsing spec, does not support HTML5, and brings with it a variety of parsing failures and quirks.

Like many DOM libraries, DOMDocument is a heavy interface that rewrites entire documents after several stages of transformation. In contrast, the walker exposes a focused interface closer to what string functions offer. For the kind of modifications occurring in WordPress this is a more natural and convenient approach.

If this resonates with you then please speak out before September 9th

This post will be open for feedback for the next three weeks until September 9th. After that @dmsnell, @gziolo, and @zieladam would like to merge the new API 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/ 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 power adding CSS classes to Gutenberg blocks, block layout improvements, and changes in CSS style variations.

Also see the WP_HTML_Walker Pull Request.

Props to Dennis Snell (@dmsnell), Grzegorz Ziółkowski (@gziolo), Andrei Draganescu (@andraganescu), Carolina Nymark (@poena), and Ramon Dodd (@ramonopoly) for their reviews and help in putting this proposal together.
#core, #editor, #gutenberg, #proposal

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

Wouldn’t stabilizing every 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. before the release slow down new features?

The goal isn’t to stabilize. It’s to avoid adding public experimental APIs to WordPress core. Here’s two alternatives to stabilizing:

What if a stable feature depends on an experimental feature?

Then it isn’t actually stable. Let’s stabilize the dependencies first (or make them private).

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 API already in Core needs to be removed?

Does it? 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 three:

  • 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.
  • Risk: Surgically removing all the Gutenberg plugin work spanning multiple WordPress releases from pre-release merges may become too complex. It would halt the merges entirely. If this risk does materialize, the merge guidelines will need to be adjusted again.

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 explored without a successful resolution.

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 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: Better REST API handling in JavaScript

This call for feedback will be open for the next two weeks until July 18th.

I propose extending the useEntityRecord hook to support editing and deleting WordPress data. It should make building features and plugins on top of WordPress REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. easier.

The hook is a part of @wordpress/core-data, 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/. package providing tools for interacting with the WordPress REST API. You may know coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-data from Redux selectors, actions, and ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 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. like  getEntityRecord, saveEntityRecords, useSelect.

Today, useEntityRecord enables easy access to data

The useEntityRecord hook enables fetching data with just a single line of code:

import { useEntityRecord } from '@wordpress/core-data';
 
// Inside of a React Component:
function PageTitle() {
    const { record, hasResolved } = 
        useEntityRecord( 'postType', 'page', 15);
    return hasResolved ? record.title : 'Loading...';
}

It was introduced to 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 in PR #38782 and will land in WordPress core in 6.1, 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..

For comparison, achieving the same result without useEntityRecords requires much more knowledge about the Gutenberg internals:

import { useSelect } from '@wordpress/data';
import { store as coreDataStore } from '@wordpress/core-data';

// Inside of a React Component:
function PageTitle() {
	const { page, hasResolved } = useSelect(
		( select ) => {
			const selectorArgs = ['postType', 'page', 15];
			return {
				page: select( coreDataStore )
					.getEntityRecord( ...selectorArgs ),
				hasResolved: select( coreDataStore )
					.hasFinishedResolution(
						'getEntityRecord',
						selectorArgs
					),
			};
		},
		[]
	);
	return hasResolved ? page.title : 'Loading...';
}

Tomorrow, useEntityRecord could ease editing data

In PR #39595, I proposed taking useEntityRecord one step further to make editing WordPress data equally easy:

const { record, edit, editedRecord, hasEdits, save } =
	useEntityRecord( 'postType', 'page', pageId );

// edit({ title: “My new title” });
// save();

// After React re-render:
// console.log( record.title );
// "My new title"

In comparison, this is how it’s done today:

const {
	editEntityRecord,
	saveEditedEntityRecord,
} = useDispatch( coreStore );

const { record, editedRecord, hasEdits, isSaving, saveError } =
	useSelect(
		( select ) => {
			const args = [ kind, type, id ];

			return {
				editedRecord: select( coreStore )
					.getEditedEntityRecord( ...args ),
				hasEdits: select( coreStore )
					.hasEditsForEntityRecord( ...args ),
				isSaving: select( coreStore )
					.isSavingEntityRecord( ...args ),
				saveError: select( coreStore )
					.getLastEntitySaveError( ...args ),
			};
		},
		[ kind, type, id ]
	);

// editEntityRecord(kind, type, id, { title: “My new title” });
// saveEditedEntityRecord(kind, type, id);

// After React re-render:
// console.log( record.title );
// "My new title"

I combed through the WP Directory and found existing plugins that could already benefit from this pattern.

If this resonates with you, speak out before July 18th!

Introducing new APIs means having to maintain them indefinitely. Therefore, I would like to confirm this proposal offers an attractive solution to a real problem. This post attempts to do just that, and I would love to hear from you! All opinions are welcome, especially if:

  • Your JavaScript code interacts with the WordPress REST API
  • You’re maintaining code that leans on wordpress/core-data
  • You’ve struggled to learn how to use it
  • This new 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. would be helpful for you
  • You’re not convinced there’s a need to introduce such an API

I’m also interested in all the code samples related to editing and saving entity records that you are willing to share. It would be a great way to validate and exercise the proposed API.

This call for feedback will be open for the next two weeks until Jul 18, 2022.

Props to Anne McCarthy (@annezazu) and Grzegorz Ziółkowski (@gziolo) for their help in putting this proposal together.

#editor, #gutenberg, #proposal

Proposal to Start a News blog on developer.WordPress.org

Update Dec 1, 2022: The Developer Blogblog (versus network, site) went live as 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. on November 18, 2022 and was announced on this blog the following Monday WordPress Developer Blog is in public beta


Staying on top of the new features coming to the WordPress open-source project is one of the main barriers expressed by developers.

The Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blog has a heavy emphasis on meeting notes for the various core teams, rather than highlighting new features. This makes it difficult for developers who are not contributors or who just occasionally contribute to find the relevant information among the team-related posts. 

To achieve one of the big-picture goals for 2022 (“Create a developer-focused communications site“), this is a proposal for creating a Developer News blog. The content focuses on updates for developers, extenders creating plugins and themes, and those who work with WordPress at an agency or as freelancers. 

Preliminary Timeline

  • Proposal and request for comment period: February 25 – March 18, 2022
  • Coordinate with Design and 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. Teams for theme (the News theme would be spectacular) 
  • Brainstorm meeting with team representatives: End of March
  • Content creation and first post: early April 2022 
  • Start-up phase: Through mid-July
  • Review and expansion to regular topics for developers: Fall 2022

Problem to be Solved 

The current developer.wordpress.org holds a ton of comprehensive documentation with examples, tutorials, getting started guides, and more. That being said, there are various improvements that could be made to make the site much more impactful. Some of these areas for improvement are outlined below. 

What’s missing: 

  • There is no changelog to signal various changes including when pages are updated or when new APIs appear or existing ones are augmented with new filters, 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., and configuration. 
  • There is no mechanism to subscribe to updates. A blog would provide this feature. 
  • Outside #core-editor meetings and GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/, there is no single place to keep up with  ongoing discussions. For example, to learn about the new styling engine, a developer needs to visit three sites: Discussion, Tracking Issues, and the first PR.

Start-Up Phase

As a first step, the Developer News can tackle the above pain points by:

  • Surfacing updates to documentation, 
  • Highlighting new tutorials, and, 
  • Providing a way for developers to subscribe to stay up to date 

The Developer News blog can also be added to the Planet WordPress feed, so post titles also appear in the WordPress News 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. in the WP Adminadmin (and super admin) Dashboard. 

This initiative requires cross-team collaboration among contributors from the Documentation, Core (core-css, core-js, core-editor etc.), Training, and Support teams. 

These teams could use an existing WP 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 for synchronous meetings, such as #docs or #core. During the meeting, team reps and other contributors can make editorial suggestions for topics and links that could be included in the next edition of an update post.

An editorial calendar can be an early agenda item for the meetings. 

After the initial start-up phase, the blog would be extended to regular topical posts relevant to developers. 

Possible Ideas for Future Expansion

  • Summaries from GitHub Discussions 
  • Excerpts from meeting discussions for distribution to a wider audience of developers
  • A post consisting of a summary of multiple dev updates 
  • Useful questions/solutions found on StackOverflow/StackExchange 
  • Reviews of existing documentation to identify gaps 

A possible future expansion would include a regular revision process to update content with new information and changelog recording. 

I recommend that contributors to this initiative comply with the Make Core Post and Comment Guidelines. Should the editorial group decide to also include highlights of example plugins or themes, all products must adhere to the Community Team’s guidelines regarding GPLGPL GNU General Public License. Also see copyright license. compliance of the products, including premium products. 

As mentioned above, these are just some initial steps to get processes and contributors in place. Reader comments and discussion in the Slack channel will surface opportunities for further enhancements. 

What do you think? How could this proposal be improved?
Please share  your comments, your thoughts, and content ideas. If you’d like to contribute to the Developer News, mention this also in the comments. The comment period on this proposal will end on March 18, 2022. 

Props to Dion Hulse (@dd32), Destiny Fox Kanno (@piyopiyofox), Tara King (@sparklinerobots), Anne McCarthy (@annezazu), Tonya Mork (@hellofromtonya), Daisy Olsen (@daisyo), Dan Soschin (@dansoschin), and Anjana Vasan (@anjanavasan) for fruitful collaborating on this proposal. 
Props to Mary Baum (@marybaum) and Jean-Baptist Audras (@audrasjb) for final review

#core-dev-blog, #developer-news, #proposal