ProcessWire Dev Branch

[ryan]

What we love to see is a image manipulation tool to cut an original image, to then create thumbnails from. Croppable image does a good job, but still missing a cut the original image feature.

This was also part of the update, but not yet finished. It'll be finished in this week's update. If you want a preview of what it does, you can click on the filename of any image (currently hidden that way, since it's not yet fully functional). It'll let you size and crop it just like in the RTE version, and then give you the option to replace the original or save as a new copy. But if you try it, no need to send issue reports just yet because it's only a work in progress at this point (the code just isn't there yet). 

Btw, it's not a replacement for CroppableImage, so if you have that need, you'll still want to use CroppableImage. The tool being added is purely about manipulating the base images in the image field, not about creating predefined/named variations to pull on the front-end. Though manipulating the base image may be exactly what you need to keep your api-generated variations from copping off someone's head, etc 

[LostKobrakai]

I think if I revisited it I wouldn't even bother with SirTrevor to be honest and I'd roll my own interface so as to keep the styling in line with the PW admin themes.

I would support that decision. It's always kinda difficult to bend preexisting styling to fit another look & feel, especially if it should adopt styling of different themes. Also I don't really like the + blocks in between all the actual blocks of SirTrevor.

@Ryan

As always a really elaborate answer. 

I can see your points and I would not suggest to acctually remove RTE's or it capabilities at all. It's just I've rarely seen clients or other potential users, which would be pleased to just have these options for images: align_left, _center, _right. Most of the time they want to be able to insert images freely at some place in the text, but it's nearly never just a standart floated image, mostly it's some kind of predefined imageplaces ("hero", "aside", "something") or even galleries of images.

There's already hanna code, but that gives a really bad user experience to let people choose images by either copying filenames or adding tags in the imagefield (these tags could also sport a more modern UI) or even not let them choose which file is displayed in a gallery and which is used otherwise. Also it's so visually unpleasing to have something like [[gallery tag=galleryimage]] while it could easily display the actual images, maybe even with simple drag and drop sorting, if this is inside the RTE or as "extra" block shouldn't really matter. It's easy to build custom imagestyling or galleries in other ways, but placing the actual thing within the RTE always feels cluncy. 

So after writing this, maybe it does only need more custom plugins like pw_image to do such things. Then I would only be left with the unsexy CKEditor modals.

[renobird]

I would love to have full featured options for both RTE and a block editor. As much as I would like to do away with RTE's — they are still relevant and essential at times. In my case, we won't be abandoning the RTE anytime soon, but there are a lot of times where a block editor would make things simpler. 

@ryan,
These new additions are awesome, and make images inside RTE (CKEditor) a lot better. Thank you!

@Pete

Your implementation sounds great! Having it look/feel like part of the admin seems ideal. Can Ryan loan you one of his clones to help get it release ready?

[ryan]

It's just I've rarely seen clients or other potential users, which would be pleased to just have these options for images: align_left, _center, _right.

Actually they can place the images anywhere they want to in the text. They aren't limited to just placing it at the top. Of course, when you find where you want to place the image in the text, then at that point you have to specify whether its an image that should be left aligned, right aligned, or centered. On the front-end, you can choose how you want to handle that. While most of the time the text floats around it, sometimes I'll take an alignment and make it pull into a blank left/right column. 

mostly it's some kind of predefined imageplaces ("hero", "aside", "something") 

Images for predefined placement in a layout shouldn't go in the text at all. You'd want to have a dedicated field or tag for those images. If there are more than a couple predefined placements, I might use tags so that an image with the tag "hero" automatically goes to your dedicated hero spot, etc. 

or even galleries of images.

 

I usually treat galleries as predefined placements (like appearing above or below the main content). Rarely does the need arise where galleries need to be part of the actual copy, but others may have a different need/experience, so I think that's a good example. While I like having a consistent placement for a major feature like that, it's really more about having markup that is generated dynamically when the page is viewed. But if you wanted the ability to place galleries of images in-between blocks of copy, then I agree that's a good use case for a block editor. Whether it's worth the compromise would depend on the need I suppose. Perhaps that's a great case for a hybrid editor that is primarily RTE but provides certain blocks you can work with. CKEditor does actually provide something called Widgets that allow insertion of more complex predefined markup elements, but I don't think it's quite there enough to where I'd want to use it for a gallery. That's because it's something I'd want to generate on the front-end rather than directly in the RTE-generated markup. I don't like RTE's generating anything other than basic markup because it's just not as portable... once you start using CKE widgets, you can't really switch to another RTE without losing those widgets. Probably what would be ideal is CKEditor with a block-editor style select input at the bottom that lets you add certain types of elements like galleries, paginations, or other things (but not simple markup elements like headlines), and then lets you continue the text content underneath in another CKE instance. That would let the RTE do what it's good at, and let blocks handle the things that would benefit from having their markup generated at runtime (like a gallery). 

[Pete]

I think the best way to put a gallery in CKEDitor would be Hanna code to be honest - only sane way I can think of

My Block editor implementation allowed multiple CKEditor fields too (in inline mode) so I'm going to stop referring to SirTrevor completely at this point as it's confusing. I'll try and revisit it this week as I think a lot of what I've been doing the last couple of days might help me get over the final hurdles with it and then I'll be confident about sharing a screenshot.

Topic thoroughly derailed now though, sorry!

[LostKobrakai]

Images for predefined placement in a layout shouldn't go in the text at all. You'd want to have a dedicated field or tag for those images. If there are more than a couple predefined placements, I might use tags so that an image with the tag "hero" automatically goes to your dedicated hero spot, etc.

Your right with the "stick a image into a placeholder" types, but actually I meant it more in the kind of predefined grid sizes or something like that. Eg. 1/2 width, 1/4 width and such things. My bad of being not precise enough.

I usually treat galleries as predefined placements (like appearing above or below the main content). Rarely does the need arise where galleries need to be part of the actual copy, but others may have a different need/experience, so I think that's a good example.

I've done this for the client behind this request,too ,but here's an example: Think of an blog post about an event. The user uploads all the photos of the event, but they are a lot of them, so the client wants to have two galleries. E. g. one for the lunch and one for the actual event itself taking place. Each should also be accompanied by the text which reviews them. 

Maybe it's just an edgecase, but until there's another way I have to get used to hanna codes and/or subpages for galleries if need be.

Topic thoroughly derailed now though, sorry!

At least it's really interesting to see how others feel about this topic.

[Marty Walker]

 At least it's really interesting to see how others feel about this topic.

In most cases I can convince a client that pooling images into a gallery is best done at the end of a page. But increasingly I'm getting requests to thread galleries into article copy. The times I've gone the hannacode route clients just roll their eyes with that "really?" look. And further looks of dread when I try to explain  that 'image 1' is actually 'image 0'.

[MadeMyDay]

E. g. one for the lunch and one for the actual event itself taking place. Each should also be accompanied by the text which reviews them.

Why not use PageTable or PageTableExtended for that?

To the topic: I also don't see a use case where I allow my clients to insert editable images directly into a RTE field because I always want to separate design and content. But nevertheless if I needed it, this implementation is just awesome. And the upcoming ability to generate thumbs of a given image in the standard image field – even as a byproduct – is the thing I am looking forward to!

What I don't quite get: All the features described above (see quote and posts before that) are already achievable with PageTable and PageTableExtended. The module still is in early stage (had no time to develop it further) but works pretty well and allows to define custom layout parts. A next step would be to get rid of the popup while editing and put the edit interface into the layout itself (shouldn't be hard with an Iframe). But I would never advocate a WYSIWG editing capability because editors then tend to "make the content fit". And this can never work considering the unexpected output on other screen resolutions/devices which an editor can't foresee. So my approach is to make the interface as clear as possible and present the content in a comprehensible way, but never in a 1:1 way, because this can never be real, neither in front- or backend.

Edit: Take this page: http://schutzbelueftung.de/montage-service/

This it how it looks like in the admin (cut-out):

[apeisa]

From editing perspective I think PageTable and -Extended do everything discussed here.

What I don't like in that is the searching. No more "body*=foo". But that's the price. On the plus side there is 100% freedom for markup (not necessarily the case with "hybrids", like using ckeditor widget).

[MadeMyDay]

No more "body*=foo".

Why not? The only thing you have to do is to identify PageTable parts, put the page containing the PageTable field in an array and display the results only once. Or what do you mean?

Edit: Ah, you mean, you have to search in more fields than just one? Well, also this is not a show stopper

[apeisa]

Definitely not a showstopper. Especially on brochure sites where there is no complex searching involved. Also if elasticsearch or something else is used, then no problem at all.

[ryan]

The other half of the images update is now in place on the dev branch. This enables you to edit images directly from the images list that you see when editing a page. When you hover an image or image thumbnail, you'll now see an edit icon appear in the upper left corner of the image. Click it and a modal opens. From there you can crop and resize, and replace the original image, or save it out to an entirely new image (copy). When cropping and then replacing an image, it will also attempt to re-create any size variations to reflect the new crop. 

This update also includes tweaks and improvements to what was posted last week. I'll cover this all in more detail in Friday's blog post, likely with a short screencast too. But wanted to go ahead and mention that it's there now if anyone is interested in testing it out. If you do test it out, do a Modules > Refresh in your admin after installing the latest dev version. This will make it update the versioned JS/CSS links to ensure your browser isn't still serving older versions. Though sometimes it still takes quitting/reopening the browser or clearing the browser cache. Please let me know how it works out for you. 

[Peter Knight]

Briefly tried it. No issues and beautifully implemented.

I have an OCD issue with the title of the modal window being upper-case. Same in ListerPro too. But realise thats off topic

[apeisa]

Seems to work great! Only glitch I could find in briefly tests was that in CKeditor cropping did lost the align setting. I had to re-edit after cropping to save the align.

[Soma]

Sometimes I can't edit an already inserted image. Does that happen to you guys too? CKeditor. I think this is or was the case since quite a long time. I get a JS error.

Does this also work with the Croppable image field as it is extending the Image field? I figures it wouldn't work on a cropimage.

[ryan]

I have an OCD issue with the title of the modal window being upper-case. Same in ListerPro too. But realise thats off topic

That's just part of the stylesheet in AdminThemeReno. It doesn't do that in AdminThemeDefault. We can ask Renobird about maybe changing it. I don't mind the uppercase myself, but it does seem maybe a little large when it's displaying anything other than a short title. 

Seems to work great! Only glitch I could find in briefly tests was that in CKeditor cropping did lost the align setting. I had to re-edit after cropping to save the align.

It wasn't coded to retain align classes through cropping, but I suppose it could. I'll look into it. 

Sometimes I can't edit an already inserted image. Does that happen to you guys too? CKeditor. I think this is or was the case since quite a long time. I get a JS error.

That was actually fixed about an hour ago (https://github.com/ryancramerdesign/ProcessWire/commit/bdf74054b3da06b1b354189381ed8c2f191b857a). I'd never seen it myself till I uploaded this version to a client site and tested it out, and then suddenly got that error for the first time. Getting those plugin.js files out of your browser cache can be a pain though. You may have to clear your cache or quit/reopen the browser. 

Does this also work with the Croppable image field as it is extending the Image field? I figures it wouldn't work on a cropimage.

Just tested and it doesn't. Looks like CroppableImage overrides the methods where this stuff is generated in InputfieldImage. However, it would likely be as easy as Horst just adding a single edit link to the output of CroppableImage. 

[renobird]

I have an OCD issue with the title of the modal window being upper-case.

That is a hanger-on from some other type styles I was experimenting with part way through working on that theme.

I noticed it a while back, but just keep forgetting to fix it. I'll make a note of it — don't want to set off anyone's OCD.

 

[Soma]

Thanks Ryan, would be cool if that could be made compatible. Not sure there's too much overlaps? 

Would this be all of a sudden the default or could this feature be "to enable"? Guess it such a great and needed feature all of it that it must be default.

[Soma]

Oh forgot to ask. What is about the ProcessLatestComments module that is in modules directory, but there's also now a ProcessCommentsManager in core?

[Peter Knight]

Just wondering about the overlap with other crop modules?

Are there plans to integrate these Image cropping modules?

Maybe have a list of pre-defined crop sizes available in a drop down. Crude mockup attached. See top right of the image.

[Soma]

Another feedback I noticed a lot. Make the body overflow: hidden (if I remember correct) when a modal is opened. This prevents the page in the back to scroll. This is the problem with all modals, Lister etc.

[ryan]

Would this be all of a sudden the default or could this feature be "to enable"? Guess it such a great and needed feature all of it that it must be default.

Yes this is default enabled on all image fields. I don't see any reason to have it disabled. 

Oh forgot to ask. What is about the ProcessLatestComments module that is in modules directory, but there's also now a ProcessCommentsManager in core?

Comments manager is only in the core dev branch. Once that becomes the new master, I'll likely remove the latest comments module from the directory.

Are there plans to integrate these Image cropping modules?

Maybe have a list of pre-defined crop sizes available in a drop down. Crude mockup attached. See top right of the image.

 

No plans to integrate at present. The crop feature added here is something entirely different from CroppableImage, and predefined crops are really the specialty of CroppableImage, which does a great job of it. The crop feature added to the core is more about getting the main/source image right, like for clients that don't have any image editing tools on their computer. It's particularly helpful in having some control over whatever variations might be created on the front-end of your site. For example: we are building a company directory and people upload various sizes of images for different people and sometimes people's heads get cut off in some variations. I'm using a square thumbnail on the listing page, and client uploads a tall portrait image. Head gets chopped off on the square thumbnail. Now the client can see "oh there's a problem there" and fix it themselves rather than calling me. That likewise fixes it for any other variations that might be generated from the same source image. No accounting for any of this is necessary in the site's code. Now I could use CroppableImage too, but I don't need this level of control for most of the images in the scenario I described, and don't want to make any changes to my site's front-end code to support it. Just want to give the client the ability to fix their own problem images when they pop up. Not looking to replace CroppableImage, which is already awesome and a great tool to use when your need calls for predefined crops. 

[ryan]

Another feedback I noticed a lot. Make the body overflow: hidden (if I remember correct) when a modal is opened. This prevents the page in the back to scroll. This is the problem with all modals, Lister etc.

I've been looking for a fix for this, thanks! Just tested locally and seems to work nicely. I will update the other modals as well. 

[LostKobrakai]

I don't know if you can fix this, but currently it's hard to get the cropping box to the edges of the image, as the borders sometimes doesn't notice the drag end if you're releasing the mouse outside of the image. Top / right seem to work fine, but bottom and left edge don't get it for me. One can always drag the whole box down to the edge, but it would still be nice to have this working in all variations.

Edit:

@Ryan

I can see that you don't want to duplicate stuff. But it would really be nice to have a single interface for editing image variations. This could even include variations generated by the api to be editable instead of just predefined sizes from CroppableModule and/or RTE images. Also now there are two seperate cropping UI's, which could each borrow a thought or two from each other, aside from the fact that just one interface would be easier for the user.

Secondly editing api variations would even enable advanced stuff like using the picture element with automatic cropping for different imagesizes, while having the ability to author the crop for e. g. the mobile view afterwards, like showing a tighter crop. With CroppableImage this would only work for fixed aspect ratios.

[pwired]

Why not apply to become a pw team coder ?