@aduth requested an update to the meeting time displayed in https://make.wordpress.org/core/ — the time being shown was wrong and it should be corrected to be one hour later.
@sergeybiryukov performed the update.
Agenda: Feature: Add webpack 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 to externalize and extract script dependencies
A pull request was proposed to implement a new module to help automate some of the processes around assigning webpack externals.
@aduth provided some context:
A problem we have today is we have the
package.json each package which lists these, then they need to be duplicated again into
lib/package-dependencies.php, which sometimes does not occur
The pull request was generally well received, people participating in the meeting noted that it may be a step to eliminate the need for maintaining dependencies in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher for plugin developers utilizing webpack or wp-scripts build workflow.
If someone reading this has any idea that would work in the majority of cases feel free to comment.
Agenda: Filterable translation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. functions
@swissspidy proposed a pull request that makes all gettext functions from the i18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. package filterable.
There was some consensus that although the filters may not have a big overhead during a gettext function call, the function is a hot path and may be called many times during the application usage.
The discussion went forward and people analyzed some tradeoffs of the following potential alternatives:
- Apply the filters on the server.
- Add a labels property to the editor setting that developers may change.
- Provide developers a simple way to extend an i18n file with another file containing their customizations.
Ultimately it seemed people were not able to decide on a solution because there is a lack of knowledge of the high level need a plugin wanting to use a gettext 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. may have.
@nerrad suggested the following action item:
experiment with actual benchmarking metrics for the filter approach using concrete examples
@swissspidy volunteered to find some concrete examples/use cases.
If anyone has some concrete examples please provide them as it would allow to decide the best path forward and would allow to have real-world measures of the performance.