This is not a great experience in core at the moment, but since some themes / people may be relying on specific thumbnail generation for galleries, it'd be good to offer that option in the inspector, to choose a specific thumbnail size from the registered ones.
A consideration is that these options can currently be filtered in core with the image_size_names_choose
filter.
@mtias by "thumbnail size" I assume you referring to a registered image size. If that is the case this might be an issue because the registered image size may not have an image size stored in the upload directory, as adding an image size does not resize the currently uploaded images.
I see @mkaz and @jasmussen are assigned this issue (as of this comment). Are either of you currently working on this implementation?
Are either of you currently working on this implementation?
I'm not, and I don't think Marcus has started yet either. We have a few other tickets to look at also, https://github.com/WordPress/gutenberg/issues/assigned/mkaz so please feel free to take this one if you're feeling adventurous, would really apprecaite it. Worst case, you can push your work early, and ping us, and we can work together.
馃挀
Correct, I'm still working on #1444 #1445 and #1447 which all involve gallery & media modal - so haven't started on this one yet
Reassigned this one to you, @kopepasah, but if it drops off your radar for any reason (understandable), just ping us and we'll be back on!
If "image block" has a combo box to choose from registered image sized I don't understand the hesitation to provide a similar mechanism for the gallery block. In both cases there is a possibility that user may not have an image size stored in the upload directory, but looking at popularity of "Regenerate Thumbnails" plugin people are aware how to deal with it (by the way it is strange that core allow changing image sizes assigned to medium and large names but has no option to handle already uploaded files).
_This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs._
Would be great if there is a solution to this (even as an intermediary step until there is better image size support/foundation in core as mentioned in the slack channel)
Think of all users that are uploading images in full sizes. This quickly adds big amounts of traffic to a site.
+1
Inserting huge full size images would break the page. Thumbnails also needed for Lightbox modules.
Could the proposed UI enhancements for images work for this as well? https://github.com/WordPress/gutenberg/issues/4914
A fix until thumbnails comes in - replace the gallery block with the gallery shortcode
https://github.com/klihelp/kli_gutenberg_gallery
I think the images in the gallery block should at least support the srcset attributes? Then the browser should be able to load only the image with an appropriate size?
@fabianpimminger Adding srcset
and sizes
only partially resolves the issue. See #6177
Think of all users that are uploading images in full sizes. This quickly adds big amounts of traffic to a site.
Like @fabianpimminger said. Currently full-sized images are being loaded when I use the gallery block on a website. This isn't accessible for people on a slow internet-connection and an unnecessary waste of resources.
I would expect the possibility to choose which image-size I want to load. Just like @mtias proposed in the opening of this issue.
Please store image attachment IDs in JSON comment blocks (<!-- wp:gallery -->
and <!-- wp:image -->
). So content can be easily filtered by backend code.
In the current version of Gutenberg only wp:image
stores attachment ID, wp:gallery
- doesn't.
If this won't happen, every plugin or theme that wants to modify Gutenberg gallery HTML markup needs to create another block. Which breaks backward's compability.
More info at: https://github.com/WordPress/gutenberg/issues/8193
I think @markfinst 's recommendation is a good one. (storing ids
.) There are a few instances I could see this being useful:
1) Gallery shortcode fallbacks to respect older filters will likely rely on ids
( https://github.com/WordPress/gutenberg/issues/1451)
2) https://github.com/WordPress/gutenberg/issues/10994 - though this issue may be a little more complicated than just getting all the ids to a single REST request, having ids
stored will help make that an option.
3) extendability
4) transform possibilities
For https://github.com/WordPress/gutenberg/issues/1451 I am exploring a classic-gallery
block that allows for inspector controls in the sidebar. A temporary solution to this issue would be transforming large galleries to a shortcode or classic-gallery
block. If we had the ids
stored, this would be easy to adjust to. @mtias, I wanted to bring this one to your attention as we continue to discuss the possibility of a classic-gallery
block.
Here's the branch where I am building the classic-gallery block: https://github.com/antpb/gutenberg/tree/add/classic-gallery
We are consolidating image handling improvements in https://github.com/WordPress/gutenberg/issues/6177. This is a good opportunity to avoid offloading the responsibility of determining the right size (performance, weight, quality) to the user and the engine doing it instead with responsiveness in mind.
Moving this out of 5.0 as there could still be some additions to the gallery block around showing certain cropped thumbnails as options, but it needs a better presentation as well.
Is this still on the roadmap?
Hi there :)
Is it still planned to add the possibility to choose the thumbnail size in the gallery block? (As well as the "Link to" feature)
It is a heavily needed feature, there's a real performance issue with large galleries (20 and more picture). So far it is also impossible to create a gallery with square thumbnails.
Hope to hear from you soon
I'm also still looking for a fix or at least a workaround for this issue: either provide a general setting what image size galleries should link to or a per-gallery setting as it was pre-Gutenberg. Any hints?
Workaround for now seems to install the classic editor or use a gallery plugin. I've just started to implement a new site for a customer and this was the first real issue. Not beeing able to choose the thumbnail breaks the thing for me.
Croping for the same size would be a partial-solution - I will try to find a styledefinition for that - croping for the same height looks not nice in my test-case.
Defining a fixed height for the class .blocks-gallery-item seems to do the trick. In my case:
.blocks-gallery-item {
height: 150px;
}
Created a consistent look with the old galeries.
To be honest, it's a disaster to not have an option to choose thumbnail size for gallery.
Any updates on this? As I run into this issue and reflect on its ramifications, I'm actually surprised the gallery block was even released in this state. Thank you!!! :smiley:
Ref the tip :
Defining a fixed height for the class .blocks-gallery-item seems to do the trick. In my case:
.blocks-gallery-item {
height: 150px;
}
Any tips how to handle the image width ? I tried the below...not working on mobile/cell phones
.blocks-gallery-item {
height: 150px;
width: 150px;
}
+1
2 years later and this is still not fixed? Why are we sending large images over cellular networks? Wouldn't be better to load thumbnail images rather than large size that would have to be converted with CSS to appear as thumbnails? WordPress prides itself on being backwards compatible but this compatibility is broke in this block component. I would strongly consider fixing issues before continuing on new features. Priority should be HIGH
Adding the images size selector didn't fix this problem. The gallery should use one size for the thumbnails and a different size for the full size. That is the problem to begin with. This should have been a release blocker.
Most helpful comment
To be honest, it's a disaster to not have an option to choose thumbnail size for gallery.