Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Media Block Editor #24224

Open
sageshilling opened this issue Jul 27, 2020 · 0 comments
Open

Media Block Editor #24224

sageshilling opened this issue Jul 27, 2020 · 0 comments
Labels
[Feature] Media Anything that impacts the experience of managing media [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@sageshilling
Copy link

Is your feature request related to a problem? Please describe.
Intro
Current issues:
*Media library takes over post/page when selecting images to add/update a block

Adding an Image Block or any other block that adds media one needs to click to select to Upload or choose Media Library or insert from URL. This brings the user outside of the normal flow in Gutenberg to the Media library screen or a dialog box to upload media.

*Gallery and image blocks have inconsistencies

Data flow from frontend to backend seems unpredictable when using data heavy blocks, like images. The current use of a caption, depending whether added on the page edit view or in the image attachment details modal, creates a disconnect of experience for the user. It’s unpredictable.

Block Editor Proposal
https://docs.google.com/document/d/1HsW-AgJryaB4_wMFIkX7PE2Q-TKI5Pfsfsjpp-Ru1Qk/edit?usp=sharing

Issues detailed below:
Media library takes over the post.
The current view of the editor when adding an image to an image block. Unable to view page/post:
image
image

Proposed solution
Solution for editing 1. Image tray of reusable image blocks for ease of adding to posts/pages. Located beneath current reusable block tab of the block inserter.
image
Image tray provides storage for media items that have been turned into reusable image blocks, similar to current reusable blocks. Ready to be included into your page/post with content. Reusable image blocks are for reuse again and again for page/post content. To use the same image differently, cropping or different caption, will require a new reusable image block. Either upload the same image again or simply change the reusable image block to regular blocks to edit. Then save, creating a new reusable image block.

(Creating reusable blocks detailed in google doc.)

  1. Eventually, the media library will open on the left from a menu pull. Tentatively, this will be an interface of what is currently the media library. It is now located on the left. Using/editing images will cause them to be stored as reusable image blocks.
    image
    Adding an image block will create a reusable image block, similar to the reusable blocks currently, with intent to have stronger relationship with data storage and accessing custom fields/attributes capabilities. By clicking on ‘Media Library’, as depicted above, the media library is displayed on the left. The media library can be displayed as dropdown, like shown above, by clicking a menu option. Images can be dragged and dropped. An uploaded image will be included to the media library with an additional step of asking if you’d like to include it as a reusable image block, tentatively.

Reusable image blocks, will intend to be for more types of media than images, and have complexity to their structure. It is meant to, eventually, provide a way to display media in the most captivating of ways.

Gallery and Image Block have Inconsistencies

Currently, a gallery block is a block with images, limited ability to edit images, and to display options. Single and gallery options should be similar to each other.
Example: Add one image to a gallery and want to resize it in a similar way to how for resizing single images. To add images by clicking the standard add image media library screen, yet when editing the gallery, it only says upload an image. It should be identical to the single image media selection options.

image

We would like to see much more consistency between single image and gallery options. It should be very easy to go from one to the other with similar options. As one begins working with images an expectation is created that image options should be similar between various blocks that handle images.
image
image
image
image
Gallery block: convert gallery to a wrapper around the core image block #24039
Consistency between image options in single image and gallery blocks #11436

Consistency in Gallery and Image block settings #50169
Solution for Gallery, image blocks inserted into gallery block or pattern grid with setting options. Needs to be developed, with image blocks displayed as gallery with ability to edit both as a gallery and individual image block in the gallery when selected. Work will include drag & drop, as well as, moving blocks within columns.

Data Flow (with caption example)
The same image can have multiple caption instances and a default caption which can be blank. Plus, if the same image is added to the gallery an instance caption is added there, if chosen. (This is an example with one attribute, imagine multiple attributes.)

This is the same image in every example. Captions have not been changed (started with default blank for caption). The image is located on a different part of the website.

Sample A: image with caption, “calm”, edited on the frontend
image
Here is the attachment details with default caption blank

Here is the attachment details with caption “Hi California”
image
Sample B: The image with the default caption “Hi California”, located in a different part of the website
image
Sample C: The image with caption, “some june gloom by the beach”, edited on frontend. Located in a different part of the website
image
Here’s the location of the data for the attachment details, the default caption in the image attachment post type as a post_excerpt
image
Here’s the location of the data for one of the instances caption, in the most recent saved edit for the post content. Also, found the default caption, “Hi California”, in the saved post content.
image
Sample D: The Image next to the same image in the gallery with another option to edit a different caption.
image
That was an example with one attribute, imagine dealing with multiple attributes.

Caption summary:

Image block with caption ‘hello’ shown on page/post:
image


When viewing image attachment details the caption is empty. This is confusing to users/editors.

image

Shows no caption which can be confusing to users

Reusable blocks (data flow)
Currently
image
No place to edit/update or add data to without converting it back to regular blocks.

Reusable block is a wp_block that refers to post id.

Solution for data flow to be discussed. Post content attributes, post meta, json, rest-api will be looked into to reach the optimal solution for data to be fluid, and stable. Stabilizing the consistency of data flow will help advance to the next generation of media blocks. Potentially, looking at ways for updating blocks and working with dynamic blocks for long term site use in mind.

Block Editor Proposal
https://docs.google.com/document/d/1HsW-AgJryaB4_wMFIkX7PE2Q-TKI5Pfsfsjpp-Ru1Qk/edit?usp=sharing

I'm thinking a global counter stored in meta, block uses post_id & counter to differentiate the block instances. Then save variables to json/ajax update post meta too, using site api.
initial block_id discussion in core-js
block_id discussion core-editor

proposal to have a stable and unique ID for every block instance
In part of working on the image block and gallery block, would like to add a block id to each block, that is unique and stable. I think we really need a stable way to connect server data to client data. One solution to connect the two could be tied to the post_id, since it changes when edits are made, we could use the post_id. Using get_post_meta (or even wpquery) we can connect the custom fields to the client. If, we have a post_meta counter value, we can initialize it as a counter value, for each block created maybe init a useEffect to create an id with the post id and count as the key as block attributes and as post_meta (99, 3, blockinfo). the block would have an id of 99 (the post) and key of 3 (the count value at creation)with 6 zeros in the middle for placeholder. For the same block custom fields can be made with the reference of 99, 3-x, value. x is determined the custom field name '3-text-color'. This would allow for pulling in initial data from the server, or updating in both client and server. *****As I'm seeing issues with the image block and media library that are expected to have the same values in both places, such as caption. ****Thank you for reading all that. If this is something that seems plausible, I'd like to pursue it. it will help integrate the fluid experience of data between the server and the client. Possibly help solve the issue of dynamic data storage.

Especially helpful for blocks with heavy data and/or sensitive data. Also, may help to potentially solve updating/maintaining blocks and dynamic blocks.

block_id discussion in meta

Why
Continue creating media for the generation users
Move toward component focus using modern development practices
Integrate data flow to backend & frontend
Increase ability to create custom fields & manage state
Increase function in mobile

Next Steps

Throughout the process, we will evaluate user feedback and make adjustments. Moving forward to have systems in place that will integrate with one another.

Guiding Principles
Ease of use
Intuitive design
Aligned with current expectations for using media editor
Fluid movement
Enjoyable experience
Providing options for style & design

@talldan talldan added [Feature] Media Anything that impacts the experience of managing media [Type] Discussion For issues that are high-level and not yet ready to implement. labels Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Media Anything that impacts the experience of managing media [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests

2 participants