Participants: @omarreiss, @aduth, @herregroen, @nerrad, @abdullahramzan, @azaozz, @adamsilverstein, @youknowriad
Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
Sunsetting the Packages Repository
It’s been proposed that all modules published through NPM be moved from the WordPress/packages repository to the WordPress/gutenberg repository.
- The packages setup is already duplicated in 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/.
- Some Gutenberg packages can’t be moved at the moment to the packages repository to avoid splitting the work between two different repositories.
- Having a unique location to publish packages.
- One less repository for WP.
- Preparation for eventual merge to core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
- Implies the potential of Gutenberg to be bigger than WordPress.
- Helps process for making in-place updates to packages for Gutenberg use-cases without going through the tedious flow of Packages PR -> NPM publish -> Gutenberg PR.
Decision: It’s been agreed that packages are to be merged into the Gutenberg repository. @omarreiss has been volunteered to create a pull request which would preserve the commit history for packages in the transition.
An Alternative to wp.apiRequest
Problem: The current argument and return value signature of
wp.apiRequest binds us to jQuery.
Proposal: Create a new, separate
wp.fetch module as a replacement, based on the standard
window.fetch browser API.
Decision: It’s been agreed to move forward with the new
wp.fetch script and deprecate
wp.apiRequest. Separately, an observation has been noted that all future work should avoid hard dependencies on third-party scripts.
(Continued from last week’s discussion)
Problem: How can we introduce breaking changes necessary for user benefit without sacrificing a commitment to backwards compatibility?
- Create separate scripts and allow the originals to remain forever.
- Downside: User impact in code size from loading many variations of the same sorts of scripts.
- Communicate a strategy to move away from the deprecated feature, then remove the feature after a predefined amount of time.
- Important that this is a well-defined timeframe, and communication is centralized.
Prior Art: Gutenberg’s Deprecated Features
- Explore options for how communication and migrations can be assured, for both developers (visibility to the removals) and users (compatibility between plugins and future versions of WordPress).
- Propose for discussion in a Core Dev meeting.
Data Module Improvements
There are two proposals by @youknowriad for major improvements to the data module:
Feedback is requested on the following tickets:
- #43731 – Use Webpack + NPM scripts to build all the things
Progress has been made by @omarreiss on a new
grunt build:dev command which symlinks the php files on systems that allow symlinking to make the PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher only workflow much smoother.
Update: Documentation for six files have been committed since WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 2018.