Images Module - Source Page

[Joss]

Sorry if this has already been discussed:

I was wondering how difficult would it be to add a default source page to an image field?

This would do two things in the context of a form:

1. Set the default page to look for an image
2. Set the default page to save an image

In the case of the first parameter, this would just change which page is selected by default in the current pop-up box. So no major change to the interface, it would just default to a page other than the current one.

The second is a little more complicated. It could work in one of two ways:

• As a hard setting that can only be changed by editing the field parameters - so it would always save to this selected page or to the current page if not enabled
• As a soft setting so that as part of the upload you can choose which page the image is added to. In this case, the field setting would simply be defining the default page, but this could be overridden on the form. A more comprehensive version of this might be to specify a handful of pages that can be accessed, or the children of a particular page, or all pages. 

Both these functions should, perhaps, be optional, so you can tie a user down or give them a bit more freedom, depending on the form.

In putting together my demo sites, I am finding several instances where I need reusable images. Especially in blocks or widgets.

Although I can create a special page(s) for these images, it would be a lot slicker if I can preselect this page for the form rather than having to navigate what could become quite a complicated tree.

Also, having navigated to wherever I have stored the image, it is a pity that I cannot then upload to that page from the form I am currently using if I suddenly decide I want a new image.

Although this does not create a full media management system, it actually comes pretty close, while still respecting the way ProcessWire works.

I have no idea how to implement this, before some bright spark suggests I go do it!!

Joss

[ryan]

Set the default page to look for an image

Maybe the ability to have predefined bookmark pages (favorites?)

Set the default page to save an image

Probably can't do this with the current images fieldtype, as the uploader is part of a fieldtype, and a field is attached to a page -- There is no way to upload images outside of the page editor. Meaning, you have to be editing a particular page in order to upload images to it. If a page has an images field, it manages it's own images. The way to achieve what you are talking about would probably be a new images fieldtype that shares a common storage area with other pages. 

[Joss]

Maybe the ability to have predefined bookmark pages (favorites?)

Yes, that could work, though using your existing system of selecting parents pages or specific pages would do it, I think. Interesting idea to add user bookmarks, though that probably should be optional since the admin may want to define a very specific location(s) for what ever reason.

On the second one, yes I see what you mean. Since basically, it would be uploading on behalf of another, predefined page, rather than the one you are on.

I suppose there is a bit of a cheat here in the fact that the upload part of the field is being "borrowed" from another page/template - for that one action you are effectively editing another page remotely. 

[Joss]

Another variation to the module could be a "show all images" link.

Rather than navigate to a particular page, this would just retrieve all images linked to any page, with the current page's images the first on the list. (the rest could be by date or alphanumerical or something.

This would need to be paginated/ajaxified (or a mix) for sites that have a huge number of images. 

[Pete]

Glad you added that last sentence Joss, I was just thinking of how long the "loading" icon might take otherwise

I actually think it might be best to have them show up from all other pages but categorised first. The logical categorisation would be based on the template name when I think about sites I've done, so "Gallery", "Campsites", "Cakes" in some of those cases, or "Skyscrapers" in ryan's case I was thinking about trying to categories them by the page parent, but that doesn't work really as many would be under a title of "Home" on a lot of sites.

I think that if this idea progressed further that categorisation by template wouldn't be a bad idea, but should be optional as it actually requires you to have thought about your template names and structure a bit

[Joss]

You could have various sort options. It depends who is using and why. A news type site that would pull images from all over the place would definitely want it categorised somehow (though they would possibly be better off with the idea that I started this post with)

A blogger, however, may well want to see their most recent images first, and to hell with the categories.

To make it even more complicated, you may want to add search by either file name or description. I suppose the file name search field would be autocomplete. 

You could make this overly complicated, but as long as all the options are in a discrete list/hidden tab, something, then it would not be a major problem..... possibly.

[Pete]

I was thinking AJAX search functionality would be good so I agree there. Since not everyone types in image descriptions it should search the page title too I think, as well as even the summary field. In fact, that could be a setting too - which fields to search on

[Joss]

Yes, searching for images is different to searching for articles where you really want to search all fields at the same time.

With images, you are looking for something specific.

In the News CMS I designed 13 years ago (eek), one of the things we did was make the images work the same as they do in a newspaper library.

So, every image had

• file name
• location
• category (images had a distinct category system)
• description and quality (BW, Grainy, pro/domestic)
• Image title
• Image summary
• Copyright date
• Source/photographer
• Notes and Restrictions (Licencing and so on)
• History (which articles it had been used in)
• Locked/Available (so images could be used for research only, but not displayed)

Now, obviously that is completely over the top for 99% of users, but shows the way images might be stored and how they would therefore be searched.

In that old library we had around 5000 (ish) images, and everyone was stored like the above. They were everything from corporate head shots to events to logos to cartoons ... (I only have the cartoons left now), and finding what you wanted was dead easy and the source information meant we had instant contact details if we wanted to see if the photographer/agency had any additional shots. 

You also have to bear in mind that the vast majority of the shots were film originally and were supplied as prints. So we did not have the meta-data trail you have now.

Sorry, that wandered off topic a bit!

[ryan]

I think that these are all great ideas. Though I've always been of the opinion that an image should belong to whatever page it is used on. That comes from my own experiences with the sites I build, and these sites typically don't need to share specifically named individual assets on multiple pages. Actually, they share quite a lot, but in a different way. When they share assets, it's with a relationship like "pull the first image from these pages" rather than "show this specific person's photo from that page". ProcessWire works especially well with the "pull the first image from these pages" type of relationship. But the problem with "pull this specific person's photo from that page" relationship is that if the owning page deletes the image or the page, then the other page referencing it has lost it. This isn't usually a problem for me because the instances where I need to share an image in that way are pretty rare. Basically, the only instance I can think of is in TinyMCE when you want to use the same exact photo for placement in more than one page. It's a nice thing to be able to do on occasion, but it's problematic to scale because the more you do it, the more fragile things become. Is this type of image relationship something that people are doing a lot in ProcessWire? If so, is that really what they should be doing? I'm not sure… but if it is, we'd probably want to solve the inherent fragility of that type of relationship before building lots of features to facilitate selection of images from other pages. 

[Joss]

I don't think this is an either/or argument so much as "what are you designing today?" (Apologies to Mr Gates)

If we take your villa site as an example, each set of images has a very specific ownership paper trail - they belong to a specific villa and therefore, quite logically, a specific page.

Even if you then have a generic promotional page that re-uses some of those images, it is reusing them based on them belonging to a specific entry. An e-commerce shop is mostly the same case.

However, if you take my Dog-Blog (http://www.pebblesthepuppy.co.uk - you are permitted to say "ahhh" when you get there), although initially the images are uploaded in relation to a specific post, I have a great need to re-use images in other posts, without wanting the association to the original post.

Thankfully, if you delete a post, you don't lose the images in WP and the new WP media uploader makes access to images across the board much easier.

Moving onto another type of site, a news-magazine style site, then many of the images you use would be from a general library because they would be reused on a regular basis. On a game site that I ran, I could use any particular screen shot ten or twelve times - in tutorials, promotions, press-releases, general illustration and so on.

Your average business site is a bit of a mix. Although most pages are pretty much "static" (as in they are not related to a series of pages like a blog), the entire site might have elements from all the above. A blog, a product/services catalogue, staff profiles, portfolios.

Any and all of those may want to steal from each other - a news item might want to show a product picture, a product might want to show a picture of the staff member that designed the product, a press release might want to repeat the nice opening picture of the industrial estate....

And so on.

Just to make it more awkward, if the product changed spec, you will probably want to "replace" the image and have that effect everything - without having to FTP into the back end.

All of these are quite legitimate uses of media. 

What I suspect we need (and I think this is part of that fine-tuning of any software that is needed to make it attractive to a broader market) is a plugin that allows how the images are used to be customised.

So, if in one content type you want people to upload an original, then that is all they will be able to do. If on another your don't want that, but only to use something from an existing library/page, then you should be able to set that.

Oh, and I think the Thumbnails functionality should be part of this rather than as a separate plugin.

After that, it is a case of sensible management by the admin.

If they restrict an image to just a page (that may risk being deleted) then that is their problem. If they would rather have "image library" pages so this is not an issue, then it is up to them to set their site up that way. 

Either way, I think we should keep the system where an image is part of a page and not have a separate, disassociated image system.

After all, if you create a library around pages you can create categories, years, tags, all kinds of nice things - if it aint broke, dont fix it.

But that does not mean you cant expand on it so, like the rest of ProcessWire, it allows the admin to create and run the kind of site they want in the way they want.

[Pete]

I think that part of this comes down to the need for such a module to check which pages an images is used on (which means another database table preferably, otherwise we have to somehow search all page content and fields), and the other part is the centralised gallery idea.

One idea that does come to mind when thinking about categorising images is to have an additional field in the images fieldtype called Category - this could be a relatively easy way of assigning page-related images to a category in the flow of the page. So on the one hand you're doing away with the clumkiness of other systems where you upload images to a gallery, then write a post and during that process you have to navigate the gallery to find the image, and on the other hand you're at your leisure to say "this image is relevant to go in the gallery, and in these categories".

Needs some thought, but I'm trying to think of the nicest way to make it so that adding content isn't extra work and at the same time making images available elsewhere.

Yes, you're then back to the issue of images being tied to a page ID so there does need to be some checking for if the image or page is deleted that it is stored against. In that case there needs to be some really clever code to either move it elsewhere or handle it some other way.

Okay, just thinking about the technicalities is giving me a headache

[Joss]

Hmmm,

Okay, this is just me thinking, so probably wont make too much sense. Here are some thoughts

####

If you search via pages/templates, then you have a potentially complicated search.

However, if you search the other direction, so search any table that is an images or cropimages table, then the search is less of a headache.

####

We could add a reference to any media upload that is stored in a central table - so basically, we have an images_index table and everytime you upload an image, it puts a reference in that table, including a note as to the first page it was associated with (this is so it can find the file)

We are not adding to the fields in any of the images tables, they stay as they are, just duplicating the reference elsewhere for another purpose. 

This could be done as standard, so that if later on if a person changes how they are working, the references are already there.

(Note: it might be useful to have a script that can search everything and create the table if you are adding this to an existing site)

###

Images (and other media) are different from other data in that they have an associated file.

Since these are all kept in one place (assetts), these are easily sourced. There is already the file manager plugin that does this.

###

There is an issue with deleting a page and therefore deleting the image.

May be that should change - the image file stays and just becomes an orphan. If another page uses it, then it gets a new mummy! (sorry, bit sick?)

###

I don't think we need to add an extra field for categorisation - just be able to upload an image to a page that is categorised.

So, if you upload to the page you are on (say a blog entry), then the category of the image is, implicity, that page.

However, if you have created a library, and from the blog entry you are able to remotely upload an image to a page in that library, then the category will be implicitly that library page (and its hierarchy and anything else associated).

That seems to be the easiest way to do this. 

You can do that manually at the moment.

• Create a library for your images with a top level hidden page and then a tree beneath that.
• Choose a page in that library and upload an image
• Save and Close
• Go to your "blog" page
• Open the image field and find the associated library page
• Select the image.

So, instead of that, you would

• Go to your blog page
• On your image field, you have a choice (radio buttons or toggle)
  • Load Image to Current page 
  • Load image to Library (either can be set as default)
• If a single destination has been pre-selected in the field settings for the Library choice, then you are ready to go
• If a choice of destinations have been preselected, then when you select the library choice, you are automatically asked to browse to the destination (or whatever is the neatest and simplest way of presenting this)
• Drag and drop your image(s) and use it.

This way, images are all stored just as they are at the moment - it is just the action of storing them that is changed.

The one complication is the Thumbnails module (which I love)

It would be nice to have this working the same way including the thumbnails. It is probably not difficult to do, actually, but care would have to be taken with how the thumbnails module is set up (what thumbnail settings) so that it matches the page you are using. Well, the admin should be left with SOME work to do!!

And goodness knows how that would associate with TinyMCE (which it doesnt at present)

Okay, all kinds of bits there .... sorry!

[ryan]

Thanks for the thinking here, these are all good ideas. We'll definitely want to expand upon the image options in one or more of these ways soon as bandwidth allows. 

[Joss]

hehe ... is that a poke at my short and concise posts??? 

[ryan]

Not a poke at all. Right now I'm focused on getting 2.3 out and some client work, so not yet at a point where I can get into development for this. But these are all good ideas that we'll get into soon. I enjoy reading this stuff and then letting it marinate on the mind for awhile. Keep the conversation going. Once I get to a place where development is near, my posts will make yours look like short posts.  

[Joss]

Now, that is a challenge.

The last proper development report I wrote was 70,000 words.....

(Damned thing didn't happen either!)

[Martijn Geerts]

You've already exceeded the 50mb data quota on this forum with only plain text.

( I won't tell pete )

[Joss]

*puts unfinished novel back on shelf*

[Martijn Geerts]

lol

[Martijn Geerts]

I just thinking about the images.

Now on the tinyMCE image you can select images from another page.

But if there's a module setting for setting a parent from where to find/browse those images/pages. (default /) Then you're are able to restrict getting images from other Pages ( wich can be deleted etc. )

This way you could build an other "pages tree" where you could store Images you want to re use often. 

[Joss]

Hi Martijn

I think I mentioned that.

That is the best way of creating a library since it uses the native PW PAges structure, is automatically categorised by the Tree (to a certain extent) and is accessible.

However, it should also be accessible for an images field and not just for TinyMCE and, ideally, you should be able to upload to that pages tree even though you are on a completely unrelated page.

The existing system is part the way there already really, at least philosophically!

[Martijn Geerts]

Joss,

Sorry, I'd miss that you mentioned that before.

Will come back to this thread, it's bed time for me right now.

[Joss]

Goedenacht, Martijn

[pideluxe]

I think a file or image manager is great for editors with limited technical background. Often users ask how to insert an image in tinymce, but being able to change it easily after that. Or they want to able to modify uploaded on the server, e.g. cropping, changing size or alter colors. Or the graphic designer has designed different versions of the image and the editor should be able to easily choose the one which looks best for him. So i think, the aspects of an image source page or library manager should be:

• Show users the uploaded content
• Uploading new content
• Searching that content in different ways (e.g. categories, pages they are used on, size, orientation,...)
• Categorize (page tree, see below) and add meta information to content (tags, description, author, copytight notices, ...)
• Alter content (cropping, size, color), integrating an Photoshop-like online-tool
• Easily insert content into WYSIWYG-editors and file-inputfields

That is the best way of creating a library since it uses the native PW PAges structure, is automatically categorised by the Tree (to a certain extent) and is accessible.

The user should be able to use the same UI as with pages to browse for content, maybe this can be achieved by a system page like the admin pages, so it doesn't clutter the normal page tree. Content could be organized by content-related sorting structures for easier finding the right content. As Pete mentioned, there should also be a option to sort it by template-usage or page-usage, but this should be done ajaxified and in an overlay as an extra option for searching by different criteria.

I think this would open up the field for new, less-techy users. The easier it gets, the more users are attracted by it.

pideluxe

[Joss]

You dont need a system page, simply a top-level page that is set to Hidden. I do that with categories, tags, articles and so on. The new system would not create this, the admin would as part of designing the image library - that way it can be moved to wherever in the normal page tree is most useful. 

The main issue is creating a field type that can then work within the existing structure.

I was just thinking about this, and it may be more logical that each image is a single page rather than is grouped together on pages.

That simplifies things a little since it can use much of the existing system.

We already have the ability to create a page in another part of the tree from the Page Field.

So, perhaps what we need is a slightly re-written page field that does not just list the titles of the pages, but can list the thumbnail in each case.

In its simplest form each page would have the Thumbnails (crop image) field, limited to 1 image and with various thumbnail sized (set by the admin), a title field, obviously, any other information related to the image (possibly also retrieving meta data).  You could set up tags, anything really.

That is the easy bit!

The new page-field variant, needs to be then a cross between the multi select page field and the image field. You can browse the image library by thumbnail/title in a pop up (probably) and select one to either be stored in a field (path) or a variation that allows you to insert into TinyMCE. You can also "Add new image" which effectively creates a new page, including selecting where in the tree it goes (within the image section).