Better image management / better integration with WYSIWYG

[mindplay.dk]

I only recently attempted to use the image-button in the WYSIWYG, and I don't feel like this really works well.

I have to add an ImageField to the page, and put in the description something like "these images are for use in the body field, and won't automatically display on the page". Looks and feels like a patch solution.

I looked but did not find something like an "image library" module - the way most CMS work, is they let you have a shared/global image library, typically organized in folders, where you can upload and reuse images on different pages.

I know I could create "dud" pages and organize images into fields, but it kinda creates the same problem of having to explain on these pages that they're not actually published or visible but just there to organize images.

Any ideas?

[diogo]

I agree and don't agree with this. Concerning the images location, Ryan explained already why the choice of keeping the images in each page, and he made some very valid points. And if you don't think of the wysiwyg fields, this implementation is very practical. On the other side, the implementation in the wysiwyg fields is too minimalistic and could be improved in some ways. I will go a bit off topic to illustrate this last point, hope you don't mind:

• The PW images process eliminates the possibility of using an external image by URL, I think it shouldn't.
• Images should appear smaller by default in the insert image view (as discussed here: http://processwire.com/talk/topic/635-thumbnails-of-images-in-tinymce/)
• Would be great to have the possibility of inserting multiple images at once
• Would be nice if we could drag the images from the image field to the text field in TinyMce (in CKEditor we can, and it's great )
• There are two descriptions, one on the image field and one when inserting the image in the wysiwyg field. This can be very confusing.

[kongondo]

Would Soma's Images Manager (in Alpha) contribute to this discussion or that's for a different use? It's installed as a page though

[mindplay.dk]

Images should be kept in the Page by default, I don't disagree with that - but should be associated with the (body) field they belong to, rather than with a separate (image) field - it's confusing to the end-user.

Can you provide a link to the clarification by Ryan you mentioned?

Would Soma's Images Manager (in Alpha) contribute to this discussion or that's for a different use? It's installed as a page though

It's a start. I'm not in love with the idea of making users type in codes to reference images.

[Soma]

To defend ImagesManager. You can select the tag to insert... and you can still use the image dialog to insert.. And also it will let you upload and track images even if you change location or image itself..

[diogo]

Can you provide a link to the clarification by Ryan you mentioned?

Sorry, I couldn't find it... Ryan, how are your plans to put these gems of knowledge on your blog? (I don't want to pressure, especially now )

[teppo]

I have to add an ImageField to the page, and put in the description something like "these images are for use in the body field, and won't automatically display on the page". Looks and feels like a patch solution.

In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way.

Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.)

Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really.

Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs.

Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable

[mindplay.dk]

I understand everything you're saying, but I don't agree - having to add a separate field for images that belong to a different field, it just doesn't make sense to me.

Basically, in my point of view, there are images (fields) and there are inline images - the latter are not independent documents, they are just part of a body of rich content.

 

I don't like having to explain to a client why it works that way, especially if the explanation is "technical limitations". Is there a better (logical) explanation for the need (desire) to separate inline images from body content?

[thetuningspoon]

For the most part, I like the way that it works now. It's not really a "technical limitation," but a matter of flexibility. No matter how you do it, it's going to be a 2-step process of uploading and selecting the image, but the PW way bypasses having to build a separate folder structure while uploading your images and then having to hunt them down afterwards, while still retaining the flexibility of using images that appear on other pages if you want to. When you "add an image to the page" you literally are doing just that--adding an image to the page.

Keeping the images separate from the individual WYSIWYG fields also allows you to reuse images more easily (in other WYSIWYGs or in your templates) and to see at a glance what images you have stored & available for use on that page.

I think that it is actually more intuitive for people who are not familiar with CMSs at all. Plus the drag-and-drop functionality and auto-resize settings in the image containers bring a whole new level of usability to the CMS. I do agree that being able to drag and drop from the images field to the WYSIWYG would be an excellent feature, though.

All of that being said, I recommend using individual custom image fields and outputting/resizing those images directly in the template with the API as much as possible. I have found that it is the most foolproof system for clients, and is where ProcessWire truly excels. Only use images inside the WYSIWYG for inline article images and never for images that are part of the site's layout.

[teppo]

I understand everything you're saying, but I don't agree - having to add a separate field for images that belong to a different field, it just doesn't make sense to me.

This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose.

Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred.

Basically, in my point of view, there are images (fields) and there are inline images - the latter are not independent documents, they are just part of a body of rich content.

Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here 

I don't like having to explain to a client why it works that way, especially if the explanation is "technical limitations". Is there a better (logical) explanation for the need (desire) to separate inline images from body content?

You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting.

Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that?

(Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.)

Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference.

Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?)

Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself

[ryan]

I really prefer to keep images in their own fields, separate from a textarea/TinyMCE field. It's not about any limitations at all. I've just found this to be the most flexible way of managing this over a long period of time. ProcessWire has always been built to what was ultimately most flexible rather than trying to do the same thing as other CMSs. But I do recognize that it's controversial and may seem unfamiliar if one is already used to a different way. I'm not against alternative patterns for this if it helps appeal to more coming from other CMSs, though not at the expense of the current one which I think is the ideal (at least for my needs). So I always try and keep an open mind about it and am open to supporting more options for those that want them in the future. 

[diogo]

Ryan, like I said in a previous comment, you explained your reasons pretty well in a post that is somewhere berried in the forums. You don't happen to know where that text is, do you?

Coincidentally, I'm striking with these problems right now on a site i'm building. I want to use CKEditor because of some things that are needed for the text, but I have to show a lot of big images in between the text. The ideal for me would be to separate the images part from the text part, but I want to give some flexibility to the editor to build a narrative alternating text and images as I trust him completely (it will be me ).

Problems:

1. It feels stupid to upload all the pictures and add them to the body of the text, as they will be all added anyway, only the text will be added in the middle
2. The pictures clutter the editor because they are quite big

Possible solutions:

1. Use the description fields of the pictures to put the text, but I will loose the styling and it just feels wrong
2. Use my image tags module to keep the editor uncluttered, maybe modifying it to accept several images at a time when text is not needed between them ({images:1,2,3,4,5} or even {images:1-5})
3. Build a new module that will let me drag the pictures inside the editor and use thumbnails instead of the whole image, maybe even letting me drag several at the same time (my favourite, but I don't have the time right now...)

[ryan]

Ryan, like I said in a previous comment, you explained your reasons pretty well in a post that is somewhere berried in the forums. You don't happen to know where that text is, do you?

I guess I'm not sure exactly what post you are referring to? But I think the guys that wrote before me nailed it pretty well. I think not everyone has the same needs when it comes to images, and not trying to suggest that everyone should think the same thing here. I'm ultimately interested in the most flexible solution that can work anywhere, and that's what we've adopted. That doesn't mean it's the perfect solution for every case. 

It feels stupid to upload all the pictures and add them to the body of the text, as they will be all added anyway, only the text will be added in the middle

I'm not sure I understand. Is there any way to bypass the process of uploading photos and typing/pasting text in the editor, in any scenario? The only thing I can think of that would be simpler is if you could literally copy the whole chunk, photos and text at once out of Word, and paste it in there. But  I don't think this is what you are talking about?

The pictures clutter the editor because they are quite big

It's good to have large source images. But if they are too large, you might want to set max dimensions in the image field. Of course, you'll also want to enable the thumbnail option for the image previews that appear in the editor. This is an important one… you don't want to have giant images consuming the editor space. 

I'm not sure I understand the problems you are running into here. Because currently it seems like the usual way of inserting images is quite good here no? Upload image(s) … when you find a place in text where you want to insert image, click image icon … select image … resize and align as needed … click insert button. It also doesn't seem like this process would be any different regardless of whether an image manager is installed or not? 

[apeisa]

I guess the pain point for most is that while they are editing text and need for image occur, they click "Image" button on editor (tiny or ckeditor). Then there is no way to upload images in that view. Also that view could have nice little image grid instead of full size photos (this: http://processwire.com/talk/topic/635-thumbnails-of-images-in-tinymce/).

Overall I think PW has nailed images & text pretty nicely and in a flexible way. The more you mix the two (images and text), the more mess you have in any scenario (harder to reuse the content on different contexts etc). I try to make nice default image placements (with few variants if needed) and really having to use RTE image placement should be the last resort. For some sites, of course that is impossible or inconvenient. 

[ryan]

I guess the pain point for most is that while they are editing text and need for image occur, they click "Image" button on editor (tiny or ckeditor). Then there is no way to upload images in that view. Also that view could have nice little image grid instead of full size photos (this:http://processwire.c...ges-in-tinymce/).

I agree on these. I have actually tried to implement an upload in the image dialog before. But it's a tricky thing, in that the destination field of the image needs to be configurable, and the image needs to go in the parent window too. So I've left that as a "nice to have" for the future, as I'm not really sure how to implement it as present.

[diogo]

The editor is very well done, I'm not trying to bring it down or something. Be aware that I'm talking of a very particular scenario here, where I want all the pictures from a page to go into the editor. Usually I would prefer to just use the images on the template directly from the image fields. So, in this particular scenario, it "feels stupid" to put them one by one in the editor, when it was so easy to drop them in the field.

Apeisa, I'm not only talking about the grid on that window. I talking about the editor itself, In this case I want the images to be big on the frontend, but then, I have 10 images 800px wide on the small CKEditor box, and have to put text in between them. In my case, I don't care to see how the image will look like with the text, I just need the reference of them, so a thumbnail would be enough. (again, very particular scenario).

--

EDIT: ok, this last problem was pretty easy to solve. In the CKEditor field I just had to define a custom css with this content:

img{
    max-width:200px;
}

Great 

Edited May 19, 2013 by diogo

[mindplay.dk]

The current approach makes it possible to share images between Pages - that's nice, but what happens if I delete a Page that contains images reference by a body-field in another Page?

I see at least 3 different common image use cases:

1. Inline images belonging exclusively to the body-field where they're used
2. Inline images shared between multiple body-fields
3. Associated images for specific purposes (non-inline use)

You can handle number 1 with the current approach, but you can't guarantee the images won't be shared with other pages, hence you can't be sure it's safe to delete a page that contains images - or worse, you may have to delete a certain page, and you will need to first somehow recover the images, place them somewhere else and update you references to those images.

You can handle number 2 with the current approach, but it forces you to create dud pages to hold the images.

Number 3 is handled perfectly, and that seems to be what this approach was really designed for - basically any inline use-case seems like a bit of an afterthought and the solutions aren't really ideal.

I looked at soma's module, but it kind of seems to solve a different set of problems.

Ideally, I'd like to have some sort of media manager, not only for images but for audio, video, documents and links to external media, as the same set of problems apply to all of those - in particular, the ability to share and track the usage of all media items. I think this is why most other CMS have a media management component of some sort? The ability to organize a media/image library into categories etc is a nice bonus, but simply being able to manage and use media in a controlled way seems more fundamental to me...

[wishbone]

I think this is why most other CMS have a media management component of some sort

Yes!! media intensive sites just need that! It's a crucial feature which makes me think of going to WP for image-intensive sites...

[horst]

Yes!! media intensive sites just need that! It's a crucial feature which makes me think of going to WP for image-intensive sites...

<not-serious>Good luck! </not-serious>

Did you know Somas ImagesManager? It could be an option, I think.

[mindplay.dk]

Yes!! media intensive sites just need that! It's a crucial feature which makes me think of going to WP for image-intensive sites...

Okay now, let's not throw out the baby with the bath water

For the time being, I had to simply use the image-field the way it was designed - in conjunction with a WYSWIYG. I keep the image field "always collapsed" in templates where this field is exclusively for use in one or more WYSIWYG fields.

It still doesn't make a whole lot of sense to me, personally - but the guys who populate the CMS are quite happy with it. One guy remarked that he likes the idea of being able to expand the image field and get an "inventory" of the images that are in use on that page.

I'd like a better solution eventually, but if the end-users are happy, it's probably not a big deal. This solution is acceptable to me for the time being, until I can find the time/resources to build (or help build) something more advanced...

[MatthewSchenker]

Greetings,

I was just about to post about the same thing that mindplay.dk posted above.

When I built my first site requiring image management, I worried about images being separated from the WYSIWYG field. I thought the client would be unhappy with it. But it turned out they actually like the idea of seeing a list of images associated with the page.

This surprised me. But now I think it makes sense. Although the images are separated from the text field...

1. This helps users visualize the page better to know what's available

2. At a glance, users can get a sense of the photographic presentation of their blog post or other page

3. Users can upload all the needed images at once

4. After uploading images, it's then simple for users to include them (same process as if they had not done an upload first)

5. I find that users think "page" more often than "site assets" anyway

This could be one of those cases where we assume one way is easier, until we actually let users try another way.

This is just my experience.

Thanks,

Matthew

[wishbone]

Sry if I sounded too rude! It was not my intention. I just want to help improving PW by reporting problems a designer and clients have.

 
<not-serious>Good luck! </not-serious>
 
Did you know Somas ImagesManager? It could be an option, I think.

yes, of course! It's a really smart module and really needed! Thank you Soma for such a great work!

We only need the access also from an imagefield, but you mentioned to be able to do it with a pagefield http://processwire.com/talk/topic/3219-images-manager-alpha/?p=31662, as did Ryan in this comment http://processwire.com/talk/topic/1188-image-inputfield-like-in-tinymce/?p=10590 ff. - well, I'll have to find out about that ;-) 

Maybe the PageField thing could be documented, to attract more people, from WP and such.

So if that comes out as intended (access to all images from textarea as well as from a field), it should be perfect! and almost exactly what I once had a developer code for a client in modX, because there is no "Images Manager module" in ModX.

And I'd really like to not have clients copy some code! They work in TinyMCE. The smartest thing would be to insert images via the default image dialog accessing the Images Manager.

I really would like to see more WP designers use PW! My intention is to help name the obstacles. Coders tend to be fascinated by the smart technology and, how could I say without offending ;-) , tend to not be able any more to understand the designers down there. It's one of the reasons why modX hasn't grown bigger (opposed to the impression it makes) as discussed in another thread.

As I designer I'm unusually persistent to understand a smart system like modX and now PW. I almost never give up. But most designers go off much easier with some nice theme in WP and make use of all the cute functions already built in. It's also a matter of time...

[Soma]

Just to defend again ImageManager... you can select and insert images in wysiwyg as usual.. just browse the pages and select the image. It's mentioned in the description. Also I don't think it's hard or complicated to copy a tag into the body.. and after saving you'll see the image and can threat it as with all image s in tinymce.. for example change the image or resize it in the editor. But I think people are too scared to even try it so it's a little hard without people testing and giving feedback to further develop it.

[mindplay.dk]

...I think people are too scared to even try it so it's a little hard without people testing and giving feedback to further develop it.

I don't find it "scary", but I have been building web sites for long enough to know that many clients will reject the idea of having to type in codes, out right.

It doesn't matter how "easy" or "clever" your codes are - code is code, and many clients want WYSIWYG and simply will not accept that.

For myself, personally, it would work great - probably much better than a WYSIWYG. But you and I are programmers. A lot of non-programmers will throw their arms up in despair at the sight of an angle bracket.

And I get that. We should be able to come up with something better for those people. Something that is as easy and as visual as a WYSIWYG, without sacrificing ease of use or introducing codes. I say we should be. I don't think it has been done yet - if it has, I still haven't found it...

[wishbone]

Just to defend again ImageManager...

Soma, no need to defend this really great piece of software!!! only there might be some small improvements...

...and no mixture between uploading from pages and from the IM. Makes great confusion, and also, we have the problem of deleted images (which is solved with your IM).

To have something like the default image dialog, but accessing only the IM – that would be great. Clients can choose the size, visually or numeric, and link to the large image.