Read the discussion highlights
@audrasjb suggested that shipping Canonical Plugins are probably a better option for most of the blocks listed in 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 by the repository owner. https://github.com/ issue. @desrosj shared the same opinion: “For a while, the use 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. plugins was encouraged. It would be great to have canonical plugins for blocks that are somehow differentiated in the UI User interface to the user as coming from w.org and can be trusted.”
On another side, @richtabor pointed out that Core should propose a more complete set of blocks to meet more user needs: “Blocks (of all kinds) are foundational to the site-building experience—they’re not just extra features, but the literal building blocks of themes and patterns. When a block is missing, it breaks the visual integrity of a theme or pattern, or simply make certain designs impossible. That’s a much more fundamental gap.” […] “I just see hundreds of people asking daily for things that aren’t there, quickly getting lost in the complexity of WordPress (install this. activate that. canonical that).”
@jorbin answered that needing to install things is an expectation from the WordPress project philosophy:
Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
https://wordpress.org/about/philosophy/
@joedolson: “With at least one – the Playlist block – I feel it should be included on the grounds that it’s currently classic functionality missing from the block editor. But overall, I think ubiquity is one of the most major relevant issues.”
@audrasjb and @karmatosed added that having dedicated working groups for each Canonical Block project may be a nice contribution experience for people wanting to contribute to smaller projects than 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/ or Core.
@johnparris: “Instead of bundling more blocks in core, could we improve the user experience for when a block is missing and make it easy to find/install right instead of showing an error? There’s more nuance of course but just thinking in general.”
@joedolson: “an element of where the boundary sits is “is this functionality or design” – fundamental design elements feel appropriate to core, for me. E.g., tabs/accordions/menus/breacrumbs, etc.”
@audrasjb: “We can also just question ourselves why it is not a feature already present in Core. For example, if we don’t have any function to manage breadcrumb trails in Core, then the block is probably 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. territory as well?”
@richtabor: “It’s not about what we want to include in core — I’d say thats the backwards approach. It should be able what people expect when building a site or page. If it’s expected, we should cover it.”
@dmsnell: “I lean on being a bit generous with thinking about additional Core blocks as long as they are generic in nature and existing web idioms. MathML is a good example where it’s definitely a minority need, but one which has been present in the web since the beginning. Blocks like the details block were delayed by two years over discussions about what it should be when again it was in the web platform and a standard idiom.” […] “I find that case-by-case basis for discussion is appropriate, while personally I like leaning on justifying why something shouldn’t be in Core rather than justifying why it should. The canonical plugins seems like a nice compromise to me.”
@audrasjb: “Once a block is introduced, it’s really hard to remove or deprecate, so maintenance / backward compatibility is an important point.” @joedolson completed: “that’s why we need to be very sure that any block we ship is using an optimal pattern.”
@richtabor: “If it’s a slider, you wouldn’t start by inserting a gallery to make a slider. You should be able to convert a gallery into a slider (via block transforms), but that’s not what most users would expect or do. Definitely a delicate balance.”
@jorbin advocated for Canonical plugins: “One of the benefits of getting these into a canonical state (ignoring the question of if they should ship with core for a second) is that core can be responsible for both backcompat and forwardcompat. When the 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. Version needs to be updated, this also will provide good examples for the community and make it easier to get more sites using the most modern version.”
The discussion ended on some consensus on adding more blocks – in Core or in Canonical plugins – but what is needed is guidelines for how to make the decision on which blocks. A proposal on Make Core may also be a good way to gather more feedback eventually.
Read the discussion highlights
This PR provides a Block_Scanner class which allows to walk through the structure of a text with blocks and do interesting things along the way. For example, add CSS Cascading Style Sheets. class names to the “wrapping element” of a block or its inner blocks.
@dmsnell wanted to request feedback on the interface: “There are a couple of new ideas he has taken from expressed pains with parse_blocks(), one being is_non_whitespace_freeform() which sounds like a mouthful, but makes it easy to detect the difference between HTML soup and the newlines that Gutenberg stores between blocks.”
@audrasjb: “I understand the need to have a more robust method than parse_blocks() but I feel concerned about having two things to handle very similar tasks.”
@dmsnell: “I hear you. this started long ago with an attempt to make parse_blocks() lazy but then I ran into problems specifically with nested attribute access in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher. for a reason I still don’t understand, with ArrayAccess things would be broken if you did something like $block['attrs']['settings']['supportsTheme'] = true and it hadn’t yet parsed the JSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML..” […] “that’s good feedback though, and I think I can do more to help clarify in the docs which is which, including adding a reference in the docs for parse_blocks().”
@jorbin: “Is this parser fully backwards compatible with parse_blocks?”
@dmsnell: “it doesn’t produce the block tree by default, but I did add in the ability to create a sub-block-tree compatible with parse_blocks(). specifically, if you want, for example, to find a gallery block and mess with it, you can scan to the gallery block, then tell the parser to produce the block tree which includes and falls inside the gallery. That lets you mix workflows because a lot of code wants to operate on inner blocks and what not, but a lot of code also only incidentally does that because we don’t have a way to express edits that are simpler.”
@justlevine: “Does this do anything to decouple parsing from rendering, or is it still intended to be hard tied into the rendering output lifecycle?”
@dmsnell: “there was a change I merged some weeks ago to optimize do_blocks() that basically frees up memory after rendering a block. Block_Scanner can technically go further and only parse one top-level block at a time, freeing up more memory. I haven’t benchmarked it, and I doubt it will be faster, but that was the underlying insight which led to the much easier 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. that was merged. This is not intended to replace do_blocks() or render_block(), and parsing has always been decoupled from rendering. It’s viable that do_blocks() could eventually use this, but not necessary and not even the most-valuable place it can be used. Its value mostly appears when wanting to operate on parts of a document or when working with the HTML of a block. for example, I believe this is going to be the mechanism we use when parsing a block’s sourced-attributes on the server for things like block bindings or short-blocks/bits/shortcodes2.0.” […] e.g. “Replace all image block url attributes” as a render-time 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..
You must be logged in to post a comment.