This is part of the Phase 3: Collaboration roadmap. The main projects are Real-Time Collaboration, Workflows, Revisions, Media Library, Block Library, and Admin Design.

Introduction

Now that blocks are able to model and express an entire site, it’s important to improve the way they can be organized, listed, and installed by users. The overall goal is to improve how blockBlock 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. management works outside the editors — for example, by allowing the disabling of blocks globally across a site, not just as user preferences.

We should connect functionalities that might already exist but are not fully developed as user features yet. For example, the relationship between single blocks, post formats, and custom post types. There’s code built in that tries to coordinate what initial block to show on the editor canvas by checking what’s the default post format (paragraph for standard posts); if the default format was Image a user would see an image block placeholder when creating a new post instead of an empty text prompt. This kind of customization is currently a bit obscure and could be more powerful if it allowed to more easily configure default block type across post types. It should also connect with other workflows like “quick post” interfaces in the dashboard.

It also means introducing more robust permission handling across the various capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). (block registration, locking, etc) so administrators can define what blocks are available for different user roles (or even what capabilities of individual blocks are to be exposed). The fact that theme.json files are inherently composable should allow for more granular handlings of capabilities in a systematic way. For example, consider a fictional author.theme.json that sets, disables, and controls what tools and settings are available for authors over the root config file.

There are a couple important block API items to list that can have consequences on user flows as well. One example is to introduce an auto-insert mechanism so that plugins can better interact with the site document (and block trees) in a way that respects user control.

Furthermore, as part of the ongoing work on patterns, it’s time to start formalizing a connection between blocks and meta fields to empower building flexibility while retaining user clarity. For example, it should be possible for an administrator to set up a custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., powered by a block pattern, where each individual block has content attributes connected to a specific metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. field rather than post content. All could be accomplished within the block editor interface.

Finally, it’s also important to improve how installing blocks from the directory works, how we handle missing block types and reinstallation, how themes and patterns could reference third party blocks, etc. This also implies better visualizations of blocks introduced by larger plugins.

Scope

This is a summary of the broad tasks we need to look into:

• Add a section next to, or under, plugins to manage blocks globally. This means expanding the current block manager to allow enabling and disabling blocks across a site.
• Introduce more robust permission handling so administrators can define what blocks are available for different user roles.
• Create auto-insert hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and APIAPI 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. flows for block types. This is a developer tool with user flow implications.
• Improve the mechanics of the block directory with better visualization of blocks bundled in plugins and better flows for themes and patterns using third party blocks on templates.
• Develop API integrations for mapping attributes to custom fields using the editor interface. The idea being blocks can provide a native UIUI User interface for managing and introducing meta data through its attributes layer.
• Allow managing categories for saved patterns. Expose other pattern APIs, like block type or parent dependencies in the user flows.
• Develop the concept of “partially synced patterns”. These allows the design layout and the style properties to remain global while the content can be locally customized.
• Extensive application of theme.jsonJSON 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. partials on groups of blocks (control settings and styles on specific templates, parts, patterns). Explore full theme.json settings objects on a per user role.

Get Involved!

Join the conversation if you have thoughts or feedback about ways to improve the workflows around blocks.

#gutenberg, #phase-3

This is part of the Phase 3: Collaboration roadmap. The main projects are Real-Time Collaboration, Workflows, Revisions, Media Library, Block Library, and Admin Design.

Introduction

The media library has been an area of slow iteration during the first phases of the blockBlock 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. editor. It’s time to put more focus on it. The main goals are to expand the media management capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., unify the block edit and single media interfaces, and improve upon the major media flows.

On the management side, it’s time to look at categorization and tagging, better handling of attached media, design improvements to the library views and filtering. Several important functionalities are already present but not presented in the best way. For example, media attachment functionality (items anchored to a specific post) is often hard to discover, the interface is not the most intuitive, and the connection doesn’t necessarily carry through other editing flows in a clear way. For larger teams, media ingestion can often be an entirely separate process from writing posts. The ability to bulk attach media files and connect them to the relevant content pieces is thus an important part of the collaborative process.

We should also revamp the image editing interface and align with the current block editor tools. Cropping tools in particular need to be unified and further improved. Iterate on how users can visualize and toggle between different thumbnails, while reducing the burden on picking the right file size (WordPress should determine that for you at runtime). Review default thumbnail sizes to accommodate current screen sizes distribution. It should also be possible to set a non-destructive duotone effect directly in the library. It’d be nice to bring UIUI User interface tools like focus point control to the library flows, so that media objects can store that information and be leveraged automatically when inserting on a cover block, or when using an image on a cropped featured media container.

When managing the media library, it should be easy to check and keep track of attribution. As we look into expanding the presence and touch points of Openverse, it’d be interesting to see how contributions to the commons could work directly from a user’s WordPress install. Another area to look at is improving handling and presentation of other media types (audio, video, files) and their connection with blocks and the block APIs. We should resurface work on a native Playlist block, ideally powered by the Interactivity API.

Finally, we should take a look at the publishing flows for media and format driven posts (where only one block type is present) to allow more expressive freedom.

Scope

• Tackle design improvements of the media library elements and see about a path to migrate to wordpress/data and newer UI components. Make it even easier to reuse and connect the media experience anywhere on the adminadmin (and super admin) and blocks plugins.
• Look into adding categories and tags support. Explore better browsing organization (for example, date headings and other improvements to the filtering UI).
• Improve inline and freeform cropping across block editor and standalone image editing. Connect cropping variations with defining custom aspect ratios across the block UI.
• Explore how patterns could be incorporated into media flows. For example, being able to preview a selection of media (or all attached media) within different media patterns quickly.
• Connect with Workflows: for example, to require certain steps, such as adding a caption, attribution, alt text, or prevent things like publishing with external images.
• Media flows and block integration should be excellent. For example, make blocks aware of attached media so that inserting an image block could automatically display unused media or allow an author to cycle through those without opening the full media library or browsing through an entire collection.
• Expose relevant media tools and actions in the command center.
• Improve presentation of media in other editing contexts, like showing small media previews in the block list view.
• Incorporate featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. in the canvas of the post editor when the single template uses a featured image block (this is a lingering task from the site and post editor interface work).
• Look at the possibility of supporting other featured media types beyond images.
• Improve upon bulk editing operations, including attaching already uploaded media to a post type.
• Explore treating focal point as image data and make it available to plugins and blocks.
• Allow operations like drag to upload media anywhere on the editor — and then maybe anywhere on the admin.
• Follow through on updates to the attachment theme template and single image expand functionality.
• Review outstanding tasks on main media blocks (image, gallery, cover, video, audio, file, etc) for enhancements and bugbug 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.

Get Involved!

What other improvements would you like to see around the media library experience?

#gutenberg, #phase-3