This post summarizes the weekly editor chat meeting on Wednesday, 24 July 2019, 14:00 WEST held in Slack.
The agenda followed can be found here.
The meeting started with @youknowriad noting that we postponed this week’s 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/ release 6.2 to the next week due to a lot of AFKs and not enough shipped features/enhancements for a proper release. Next week we will resume the regular release schedule.
Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!
- Working on the settings page. It’s not finished yet, but @tellthemachines created a PR up to get feedback: https://github.com/WordPress/gutenberg/pull/16626
- Started working on a caption for the gallery block: https://github.com/WordPress/gutenberg/issues/9342
- Looking at http://gutenberg.run/ and other possibilities such as https://tugboat.qa/ for setting up preview environments for our PRs.
- Worked mainly on “A11y Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Navigation mode” and “Live Drag and Drop experimentation”.
- Reviewed: new PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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. to register style variations and some small reviews here and there (Gutenberg experiments settings page, Text alignments in the 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. heading, Improved preview component…).
- Started thinking about Full Site Editing and what does it mean for Gutenberg to support editing the full site/page even outside post content.
- Working on 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. screens
- Exploring some Block Template flows
- Reviewing PRs
- Plans to finish the work related to block style variations, some PR’s will need an update to avoid PHP anonymous functions.
- Will submit some fix for issues opened affecting the blocks widget screen.
- Plans on reviewing anything design stuck in the backlog.
- Has been dipping into the ‘needs testing’ label a bit to keep that moving along.
- Is working on ideas for “updating the publishing flow”. A PR https://github.com/WordPress/gutenberg/pull/16715/ is available, and feedback is welcome.
- This week: Worked on improvements to the Gutenberg Starter Theme.
- Next week: Will focus on the Patterns API + Tips.
- Worked on a PR to add basic spacing/dimensions controls to the Group Block. https://github.com/WordPress/gutenberg/pull/16730
- Improved BlockPreview component:
- Autosizing / scaling previews – https://github.com/WordPress/gutenberg/pull/16113/
- Updating the API of the component to accept multiple blocks as arguments – https://github.com/WordPress/gutenberg/pull/16033
Growing list of open PR’s
@youknowriad made a remark saying:
The list of open PRs is growing. That’s great, I’d like to thank you all for your contributions. This also means we’re having some trouble to keep-up with reviews… I’d like to ask everyone creating PRs / working on Gutenberg to help as much as needed with PR reviews (it doesn’t matter if you think you have the required knowledge or not, all reviews are helpful and help move things forward).
So please review PRs as much as you can and again thanks all for your work/help. If you’re hesitant for any reason, my DMs are open, happy to address your uncertainty.
@karmatosed flipped the question and asked if there are any hurdles to people reviewing.
@brentswisher pointed out that his hesitation (maybe shared with other contributors) is a fear of uncertainty about what would happen after something is reviewed and made the following questions:
- Does it just get merged?
- Does someone with more experience look at it again before merging?
- Am I supposed to merge it?
@karmatosed and @youknowriad answered that since @brentswisher is a member of the 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/ Gutenberg team, he can merge a PR after the review or review it anyway but not merge it right away and ask for a second opinion.
Both also mentioned that maybe there is space to iterate the docs and make that more clear.
@paaljoachim is wondering if other have some comments on PR https://github.com/WordPress/gutenberg/pull/16557 (Try: Always collapse block alignments), for @paaljoachim the PR seems a no brainer by placing alignment into a dropdown.
@karmatosed said that she would say “yes” to the PR if discoverable, but her concern is hiding usefulness.
@mapk said he liked it, adding that we have other items that work this way already.
@paaljoachim asked for comments on the previously referred PR and PR https://github.com/WordPress/gutenberg/pull/16682 (“added alignment to the toolbar for consistency”).
@karmatosed said we could add the comments and thanked @paaljoachim for championing these PRs.
@desaiuditd asked for comments on PR https://github.com/WordPress/gutenberg/pull/16244 (“Allow changing Block attributes dynamically in InnerBlocks template”.).
The idea of the template is to provide a set of blocks that prefill a given InnerBlocks when it is empty.
If I pass a template when a block contains a given set of attributes, and later I pass a template where blocks contain different attributes, nothing should happen because the block is not empty anymore and there is no need to prefill it.
The discussion continued on the reason why sometimes the template updates the blocks. @jorgefilipecosta explained that it only happens when templateLock=all and only for cases where blocks changed positions or were removed/added because for this locking we know the user would not have made these actions.
@chrisvanpatten and @mcsf both pointed to a PR that may bring more control to templateLock https://github.com/WordPress/gutenberg/pull/16678 (Template Locking: read-only / disable editing attributes)
@jorgefilipecosta concluded that for now if there is a need to update the attributes of a child, from the parent, the best solution is the usage of updateBlockAttributes action in the parent, and not use the template mechanism.
#core-editor, #editor-chat, #summary