This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 4th December 2019 held in Slack. Moderated by @ellatrix.
Full Site Editing and themes
The idea here is to recap what’s being worked on, what has been discussed in #themereview yesterday’s meeting and provide some space for feedback and discussions about the next steps.
– Summary for yesterday’s #themereview meeting
– Documentation for the current state of Block 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.-based themes
The main takeaways/action items for me are:
– Let’s have theme authors experiment with these in Github GitHub is a website that offers online implementation of git repositories that can 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//personal themes and provide feedback: Gather a list of Missing blocks?
– Potentially help build a demo theme 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/ in this folder https://github.com/WordPress/gutenberg/blob/master/lib/demo-block-templates/index.html
– From the editor side, continue on the current PRs/work https://github.com/WordPress/gutenberg/labels/%5BFeature%5D%20Full%20Site%20Editing
Sounds good to me, in addition we will also be doing more to get stuck in and help you all out with comments, PRs and testing as we all make time for it in the coming weeks.
If I’m a theme author and read these incredibly helpful links and have some questions or comments, where should I put them?
I think at the moment (only during experiment phase), it should be fine to ask here and raise Github issues for bugs. We should also take these as opportunities to document things as we move forward from both themers and devs.
I’d like to share the new priorities post for December in case you missed it https://make.wordpress.org/core/2019/12/03/whats-next-in-gutenberg-december/
An emphasize on Block content areas / Full site editing and also a push for Block Patterns APIs and usage across blocks and inserter in addition to a few tightening up items.
I’ve been focusing more on framework-y stuff:
– Get types checking in place https://github.com/WordPress/gutenberg/issues/18838
– A never-ending crusade to stabilize Travis build
Hoping in the next week to revisit some feature work:
– Better _fields handling in wordpress/apiFetch and/or wordpress/data
– Revisit spoken messages in Notice pull request
– Also been fixing up a few theme interoperability issues, notably around background colors for custom editor styles:
I’m somewhat looking at deprecating the wordpress/nux package but mostly reviewing PRs this week.
I’ve been working on “Lighter block DOM: detached controls in popovers”, improvements on Popover, multi block selection, and paste on multi block selection.
I’ve been working on…
…a PR to allow parent blocks to capture the Block toolbars of all child blocks which is just waiting on a thumbs up from @jorgefilipecosta:
…adding justification tools to the Navigation Block:
– Reviewed some media-related PR’s, namely the refactor to the gallery, to increase reusability with the native mobile APP.
– Helped the enhancements to useColors and merged the PR that uses the hook in the paragraph.
– Finish the remove editor module usages in block-editor by applying changes to the reusable blocks, rich-text, and native inserter. Some PR’s are waiting for a review.
– Updated the release tool to move readme and changelog files to the Github repository.
– Submitted several bug 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.
– Continued the interactions/enhancements on the PR’s I have open e.g.: custom gradients.
– Increase my involvement with the FSE work (by reviewing PR’s and working on a subtask — Suggestions for a possible subtask are welcome 🙂 ).
– Continue giving my support to some media-related PR’s by reviewing and testing them, and maybe submit follow up enhancements.
– Rebase Update the buttons block PR and try to unblock the PR.
– Address reviews Add a mechanism to set a width on withViewportMatch https://github.com/WordPress/gutenberg/pull/17085.
– Fix some widget 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. related issues.
I’ve mostly trying to make sure everyone is not blocked and also worked on some PR’s related to the block toolbar/UI User interface (fixed toolbar, select/edit modes…) and some code quality refactorings.
I have a PR for adding background color support to the Columns block:
I have a small docs PR that explains how to work with the changes to serverSideRender location: https://github.com/WordPress/gutenberg/pull/18722
– Worked on fixes for regression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. introduced in the block toolbar.
– Refactoring towards using the new accessible version of Toolbar component.
– Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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. to simplify the process of updating Gutenberg packages after every 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 release.
– Resume work on Patterns 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. once we decide which blocks should be integrated (Table?, Cover?).
Resume work on Patterns API once we decide which blocks should be integrated (Table?, Cover?)
We have Columns block integrate, we use some sort of setup step for Table block, should we integrate it with Patterns API as well?
The challenge is that it needs to allow the custom creator as well.
We tried Media & Text but we abandoned this idea
Information here: https://github.com/WordPress/gutenberg/pull/18343
There was additional conversations about patterns and transforms during the open floor: https://wordpress.slack.com/archives/C02QB2JS7/p1575469981089100