cb2004 Posted March 16, 2015 Share Posted March 16, 2015 So, I am looking into Processwire for a new site and I am using the dev branch. I really like it so far and can see great possibilities. What I am finding confusing is that to add images to the RTE you have to have an image field on the page. When an image is added to the RTE this image is added to the image field, if images are in the image field then these are available in the RTE. Now, surely this leaves for confusion in the displaying of images in the frontend. The image would be displayed in the content (RTE) and the designated area of the image field. I am also finding it confusing that there is no media manager so to speak. If I wanted to add an image that is already in the system I would have to find the page first where it was added? This could get quite clicky. Liking what I see so far, just wondering how people would attack these issues? I appreciate the image stuff in the RTE has only been added recently so there may be plans for improvement in the dev branch. Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 16, 2015 Share Posted March 16, 2015 This thoughts have come up every now and then here in the forums. But after some time of getting used to this most people do like the fact that files are just where they are needed: stored in the page which it belongs to. It's actually more powerful and structured than having just a single bowl of files. There are also no plans to change the way images are stored. To make this more concrete: An RTE field cannot store any images. Most cms's hide that fact, by including their media managers directly into it, but this decouples the images completely from the page structure. If you're worried about your clients being confused by this, you should be able to hide the images field for them, as the latest dev version added the ability to upload images directly from the RTE images modal. The flexibility comes if you think about multiple imagefields. E.g. one for the big heroimage (single), one for the RTE images (mutiple) and maybe one for generating a optional gallery (mutiple). Each field for it's own concern and seperated by the page they are used on. If you compare that to a media manager where all those files are bunched together, I would rather take the processwire approach. Another example: Think of a list of pages representing different clients of the website's owner. All of them have a logo and semantically the logo belongs to the client, that's why it's on a page with all those other informations like names, address and stuff. If you would link the image from a media center you would need to maintain the images seperate to the clients: Go to page, change the name; go to media manager, change the logo (if it's that easily replaceable). In ProcessWire you can change both in one place and other pages using the image will update as they most likely will be field dependent (if used via the api, they are for sure) and not dependent on a specific imagefile (don't know if the RTE's do update automatically). 6 Link to comment Share on other sites More sharing options...
cb2004 Posted March 16, 2015 Author Share Posted March 16, 2015 If you're worried about your clients being confused by this, you should be able to hide the images field for them, as the latest dev version added the ability to upload images directly from the RTE images modal. I think this is where I am getting confused. I played with the visibility settings thinking, add an image field then the page has an image field, just hide it so it doesn't appear on the backend. Unfortunately when you click upload image in the RTE, because this is set to not display, it doesn't display here. I am thinking a new visibility setting could be introduced to image fields along the lines of 'Display in Select Image plugin only'. Link to comment Share on other sites More sharing options...
horst Posted March 16, 2015 Share Posted March 16, 2015 @cb2004: welcome to PW and the forums. Uploading through / or from within a RTE field is a very new feature in PW. I never have done it 'til now . But I also try to organize population of content where & when ever I can with other fieldtypes. So, this 'Display in Select Image plugin only' - visibility - setting may sound interesting. Link to comment Share on other sites More sharing options...
cb2004 Posted March 16, 2015 Author Share Posted March 16, 2015 Well I think a new visibility setting will keep things organised, which is what I like. Field 'RTE Images' with 'Display in Select Image plugin only' would hold any images for the RTE, field 'Page Images' with 'Always open' could handle the images outside of the RTE area. Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 16, 2015 Share Posted March 16, 2015 I think currently the upload in the modal does only "emulate" the upload while via javascript the image is added to the page itself. Therefore you can't "hide" the field, as this actually keeps the field from rendering all together, so the upload via javascript can't find a field present in the page. What you can do is use the collapsed option. the field is collapsed to the title/label only, while the inputfield is still rendered and targetable by any javascript. Link to comment Share on other sites More sharing options...
cb2004 Posted March 16, 2015 Author Share Posted March 16, 2015 Yeah that's the way its going to have to be done currently. It just adds another layer that you would have to explain to the editor, make sure you upload images used in the RTE to x and upload images you don't want to add to the RTE content area to y. Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 16, 2015 Share Posted March 16, 2015 I think it's actually more easy that way. If you're using images in different contexts, so that you need separate image fields, than you'd need to differentiate them in each other system as well. And I find different image fields for different contexts much more logic than tags, or categories, or really anything else where all images are equal by default. Edit: The fact that images uploaded to the RTE appear in a separate imagefield as well (for storage) is not that hard to grasp and explained once should not make any difficulties. Link to comment Share on other sites More sharing options...
cb2004 Posted March 16, 2015 Author Share Posted March 16, 2015 Edit: The fact that images uploaded to the RTE appear in a separate imagefield as well (for storage) is not that hard to grasp and explained once should not make any difficulties. You never know what a client expects, and its a change from what I am used to is all. I personally don't think they should appear in an imagefield as well. You can add/delete/edit images directly in the field which then breaks functionality in the RTE. Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 16, 2015 Share Posted March 16, 2015 (edited) Exactly that happens if a client goes to your central media manager and deletes an image. It's a natural flaw of RTE's that they store filenames which break if one deletes the file. A RTE is not an image manager. It's a texteditor. That's why you always need some extra place where images are stored. In either way: You need to communicate to your editors where images are stored, so they can manage them (and not only upload till extinction). If these images are in the page, they are editing, or in some central hub shouldn't matter to them to much. That's where I personally think it's easier to tell them the images are stored right next to the RTE they want to use it in, instead of some other place, which is quite unrelated to the actual page. It's really the same problem, only the images are displayed in different places. You can read Ryan view about that and how ProcessWire handles deleted and updated images here: /blog/posts/quality-assurance-for-images-in-rich-text-fields/ Edited March 16, 2015 by horst corrected URL mismatch 3 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now