Below is a summary of the discussion from this week’s JavaScript 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/. chat (agenda, Slack Transcript)
Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
Agenda: Deprecation policy
Slack Conversation
Gutenberg 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/ has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin 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 to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.
It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github 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/ and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:
- Packages follow semver, so something could be removed in a major version, ie. 3.0
- Then the package adds a deprecation warning in a minor version before that, ie. 2.x
- The deprecated call as used by packages wouldn’t include anything specific about Gutenberg, but somehow Gutenberg extends the message it logs (by filter 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.), analyzes the generic deprecation version (the npm SemVer) and maps it back to an equivalent Gutenberg / WordPress release.
Actions
- Explore extensibility of
deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad) - (Re-)consider how and where to define boundaries between packages and core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-specific JavaScript (proposal by @atimmer, @omarreiss)
Open floor: Also allow building in src
Slack Conversation
The build step that was introduced in #43055 seems to cause quite some friction for PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.
It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.
Actions
@omarreiss will work on a patch 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..
Open floor: Guidelines for including WP packages
Slack Conversation
Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:
- if the plugin author needs to backport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. these API 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.’s or not in order to support classic editor.
- If the plugin author uses ES2015 or older versions of JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors..
- If the plugin author uses a build proces.
Actions
@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.
