Gutenberg: Gallery: figure out way to fallback to shortcode

[mtias]

There will be cases where it's important galleries just output the shortcode for compatibility. How could we expose this? A setting in "settings -> media"? An add_theme_support call? A setting in the inspector?

[westonruter]

An add_theme_support( 'blocks' ) call makes sense to me. This could eventually unlock additional functionality, like full-bleed alignment, layout management, and other features that perhaps cannot be reliably added without themes opting into support. There would need to be a full list of the things that a theme would need to implement when they affirm they support the blocks feature.

[mtias]

There would need to be a full list of the things that a theme would need to implement when they affirm they support the blocks feature.

This makes me think we should have specific add_theme_support or an array of configuration that includes different assertions (single column theme, content width, etc).

[jasmussen]

So, existing content will work in the freeform block. We have a pretty cool new gallery block, with a column slider. We are probably going to want to recommend this new block going forward.

I'm not sure I fully understand in which cases it's important to just output the shortcode. Would the following flow address this issue, for example?

1. Insert gallery block, make a "new" gallery
2. Open inspector
3. Click "convert to classic gallery" button in the inspector

[youknowriad]

We do have conversion from Gallery Shortcode to a Gallery block. Is this what's this issue is about. The opposite transformation doesn't make much sense to me. We should try to improve the Gallery Block to be the default right?

[mtias]

We should try to improve the Gallery Block to be the default right?

This was in the case of plugins working with a dynamic gallery—tiled galleries, etc. It might be plugin territory.

[danielbachhuber]

Related #5972

I couldn't find an issue specifically for it, but we'll need to decide on how we want to handle support for the post_gallery filter (either supporting it, or considering Gutenberg support an enhancement).

[tofumatt]

Sorry, I'm just getting around to this issue and I don't understand it at all. I think there's some context missing?

What are the steps to reproduce the issue here? I'm not quite sure where to start.

[danielbachhuber]

@tofumatt I can give you a walkthrough if you'd like (and we can post the video here afterwards). It's a relatively nuanced issue.

[tofumatt]

Sure thing! If you wanted to just post a video that works for me, but if you wanted to setup a time to meet/skype/whatever that's cool too. Just ping me on Slack if you wanted to meet for a walkthrough and we can work out a time 😄

[danielbachhuber]

@tofumatt and I chatted on Zoom today. Here's a video recording of the call: https://www.dropbox.com/s/ihm9zedsd2onn7s/20180814galleryexplanation.mov?dl=0

@tofumatt may provide a summarized transcription of the call at some point in the near future.

[antpb]

I finished listening to the zoom @danielbachhuber and @tofumatt provided. Thank you so much for recording that. I wanted to post a summary here so we can get some traction on discussion.

It seems the big issue with the Gallery block in terms of backwards compatibility, is that it bypasses the post_gallery filter.

Many developers build custom gallery implementations by using that. The current Gallery block is more static than the previous so we have issues when things like an undefined id gallery shortcode that produces a gallery of images associated with the post. That association is dynamic. The Gutenberg block loses that functionality.

[gallery]

When the [gallery] shortcode is converted, we create a gallery block from the ids associated at the time of converting to the block. If the user adds more attachements to the post after converting, the gallery will not update when those changes are made.

I have some thoughts that may be helpful or at the very least start of discussions toward a plan:

I’m wondering if we could have a theme support option that can fallback to ServerSideRender. This would ensure that we hit the post_gallery filter. We could communicate out to theme/plugin developers that the option is available and their way to get Gutenberg compatible would be to set the option. We can keep gallery as is and depend on the theme support to set the type. This assumes a lot, but does that sound like an option forward?

[danielbachhuber]

It seems the big issue with the Gallery block in terms of backwards compatibility, is that it bypasses the post_gallery filter.

Yep, more or less (e.g. #5972)

I’m wondering if we could have a theme support option that can fallback to ServerSideRender. This would ensure that we hit the post_gallery filter. We could communicate out to theme/plugin developers that the option is available and their way to get Gutenberg compatible would be to set the option. We can keep gallery as is and depend on the theme support to set the type. This assumes a lot, but does that sound like an option forward?

This seems like it could be an option. I don't have a strong opinion about it as a solution though. I also don't have any great ideas on how we should make this decision at this point.

If we were to prioritize backwards compatibility, then it might make sense for WordPress core default to ServerSideRender, and then allow themes and plugins to provide their own enhanced galleries.

[tofumatt]

To be clear: I've had a bit of a look at this but didn't get far and am un-assigning myself because I don't think I'll be able to get to this before WordPress 5.0. If that changes I'll have another look, but I think it's best to find someone new to work on this.

(Thanks for looking at it again, @antpb.)

Reading through this more and understanding it... I could actually see the merits in defaulting to ServerSideRender for this at least for WordPress 5.0.

[antpb]

I think this is a 5.0 task. I am still evaluating the remaining tasks for Media. I don't want to assign/commit this to myself just yet but I think I can be of help in this.

On the chance someone comes in and can tackle this before me, I have an example of what is needed to accomplish the server side rendering bits.

With the playlist block PR you can find how I'm storing/passing the attribute of ids to the wp_playlist_shortcode function:

here's that PR: https://github.com/WordPress/gutenberg/pull/9169

Classic Editor galleries work similarly to playlists in that it is primarily dependant on ids and the rest kinda works itself out in PHP land.

The part to be discovered is how we will conditionally do either Gutenberg Gallery Block or ServerSideRender based on add_theme_support

[antpb]

I've started work in the above PR on an approach that sets the render callback based on has_filter( 'post_gallery' ) . I'm having issues currently in registering the render callback. Would REALLY appreciate if you could have a look @danielbachhuber . The way this PR sits, it should be defaulting to render_callback on a front end render of the content. For whatever reason, it is not. Going to continue plugging away at this issue tomorrow.

[danielbachhuber]

@antpb Have you gotten sign-off on the proposed implementation? I think it'd make sense to do so before you invest too much time into a pull request.

[antpb]

Happy to pause to get sign off. This was discussed a bit in the media meeting last week and it was mentioned that we could explore if post_gallery dependent ServerSideRender would be a decent option. Luckily, I didn't put too much time on this. Just wanted to get familiar with the problem and options. I'd love to get an agreement on the path forward some time this week. :)

We have three possibilities that I see going forward on this (feel free to suggest others):

1. Make a somewhat refactored 5.0 specific Gallery block that defaults to shortcode for sake of compatibility
2. Make the render_callback conditional based on if a post_gallery filter exists (example in PR mentioned above)
3. Add theme option that controls the behavior of the block. The option would give two options: shortcode fallback and new Gutenberg Gallery. A dev would be able to add the theme option which would allow shortcode fallback to support the post_gallery filter.

@mtias do you have any thoughts on the above options?

[markfinst]

Proposal

Render gallery only on server side.

• On the actual website, gallery renders how theme wants (via post_gallery filter). Majority of themes support this filter.
• In Gutenberg Editor, a gallery is rendered just as a list of image squares. With two additional features that are currently unavailable:
  
  
  
  • Drag to reorder (without having to open Media Library).
  
  
  • Click on the image shows its fields (Title, Caption, Alt) in right options sidebar. If it's hard to implement - open Media modal.
  
  

Advantages:

• It's easier for the user to edit the gallery
• Theme or plugin developers can override the gallery, instead of creating a new block.
• A user can now define "Alt attribute" and other fields for individual images.
  
  
  
  • The current implementation of the caption ("Write text..") does not actually update image attachment data. So users have to update "alt text" in one place, and "caption" in another place.
  
  

Disadvantages:

• A gallery within Gutenberg Editor looks differently from the actual website.
• Modifying visual options (for example "Columns") does not have any effect while in the editor

If these two are a big issue, gallery block can be displayed as squares only after user clicks (or focuses) it. Or when the user clicks on "Edit Gallery" icon.

Example mockup

[joyously]

Why do you keep mentioning themes and theme_support for a core shortcode?
Please don't misuse the theme_support function for something that isn't a theme thing.
Isn't it possible to have shortcodes in posts that are never edited with the new editor?

[antpb]

What was needed in this issue was a way to parse the ids from the Gutenberg gallery. This has been achieved in https://github.com/WordPress/gutenberg/pull/11540 so I'll be closing this.