Gutenberg: Allow cropping of images from inside the content editor

[mor10]

Carried over from Trac ticket 41466:

In user testing, several people have requested the ability to crop images in the editor context after they have been placed. The expectation seems to be that this should be possible, and the abstraction of having to go to the edit media panel to do this results in the user having to crop the image multiple times to "get it right".

This suggestion has several significant sticking points:

• The idea of cropping images to "fit" within the context of content makes no sense when considering RWD.
• Users who crop images also expect to be able to uncrop them later or in other contexts when the image is reused.
• Hard cropping images by changing the file is becoming a somewhat archaic practice thanks to CSS masking and cropping.

Possible solutions:

• Provide tools for theme developers to provide display sizes and shapes for images in the editor through CSS and take full advantage of RICG image scaling (related to Trac ticket 35094).
• Allow "soft" cropping through CSS (introduces complications with RWD, but better than hard cropping).
• Disallow cropping at all.

[mkaz]

We have an experiment that extends the Image block with extra capabilities including crop, plus rotate, flip, and we added in some fun photo filters from a previous project. Here's a gif to demo the features:

You can download a plugin to test it out from: Rich Image 0.1.0

The source is available in the same repo: Automattic/block-experiments

We'd love to contribute this to core, looking for guidance to see what the best approach might be.

cc: @jasmussen @johngodley @mtias

[simison]

Neat! Would love if these would be implemented in a way that it's easy to apply them to different image and gallery blocks. 🎉

[jasmussen]

different image and gallery blocks

That's an interesting expansion from being just the Image block, but a good one to note. With the simplified DOM that Ella has been working on, and the unification of all block controls into a single toolbar in https://github.com/WordPress/gutenberg/pull/19344, we are close to a point where changing the Gallery block to be a container with nested Image blocks would be a perfectly fine interaction (considering captions, mover controls, etc.). In such a world, presumably the very same cropping and editing tools would work on each item in the gallery.

[simison]

we are close to a point where changing the Gallery block to be a container with nested Image blocks would be a perfectly fine interaction

That's a fine goal that I totally support but what I meant was that block authors could easily use these features from the core without needing to re-implement them or without needing to use core-image block. A comparison could be supports object and how easy it is to add "aligment" support to your block.

In pseudo-code it could look something like this;

<ImageTools features={['crop', 'filters']}>
  <Image />
</ImageTools>

[johngodley]

@simison yes, if this is to go into core then that would be the way to go. Currently it's been designed as a plugin, not an addition to core, allowing us to more quickly decide upon the functionality .

[azaozz]

This looks great!

Just wanted to mention that the (old) image editor in WP is way overdue for update/refactoring (or rather full replacement). :)

[richtabor]

@mkaz, where should we leave feedback for the current experiment? I have some thoughts for the cropping mechanism. On Automattic/block-experiments, or here?

[jasmussen]

@richtabor While either is fine, it seems like here would be the best place as our hope is to donate this to the core project!

[mkaz]

With 5.4 stuff mostly out of the way, and G2 merged in, I figured it is about the right time to get this experiment moving. A draft PR was started at #20637

Feedback and testing welcome!

[lancewillett]

Work continues here: https://github.com/WordPress/gutenberg/pull/21024

[spacedmonkey]

There needs to a trac ticket created for porting this functionality to core. For example, unit tests need to be written for the rest api in PHP.