Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
Agenda: Deprecation policy
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.
- 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.
- Explore extensibility of
deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)
Open floor: Also allow building in src
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 5.6.20 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.
@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
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 a build proces.
@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.