21 replies to this topic

[MadeMyDay]

Quick question: Is there a module/inputfield type for images like the one in TinyMCE where you set pages and get the images listed? This would be very handy for avoiding that clients upload images again and again.

Thx in advance!

[ryan]

What you are referring to sounds like a type of page reference, and I think you could use the Page reference fieldtype to achieve this pretty easily. Let me know if I can provide additional detail. But if you've got an instance where repeating the same image(s) is expected, then my preference is usually to code the template to pull them from a common page. For instance, in the default site profile, all the site's photos are on the homepage, and the rest of the site's pages pull them from there (at least for pages that don't already have photos uploaded to them). This is a technique I use on almost every site I build. Every page has an dedicated field for interface images. If no images are assigned to it, then it pulls from a common page, or the closest populated parent.

[MadeMyDay]

Hi Ryan,

What you are referring to sounds like a type of page reference, and I think you could use the Page reference fieldtype to achieve this pretty easily.

Exactly. But not as a select for the page name (or the images url), more a visual approach by listing the images in a grid for example. Pretty much as Atti's (I think) inputfieldImageFlickr-thing. Thought about reusing this module but not by pulling flickr images but all images on the site (perhaps categorized by pages). I will take a look in the Page reference fieldtype.

But if you've got an instance where repeating the same image(s) is expected, then my preference is usually to code the template to pull them from a common page. For instance, in the default site profile, all the site's photos are on the homepage, and the rest of the site's pages pull them from there (at least for pages that don't already have photos uploaded to them). This is a technique I use on almost every site I build. Every page has an dedicated field for interface images. If no images are assigned to it, then it pulls from a common page, or the closest populated parent.

yeah, of course. This is the way I did it this in MODX. But it would be handy not only to pull standard values (parent or special page) and also not only define by page name but more visual by clicking on an image. Like in TinyMCE. But the approach in TinyMCE is different I guess because the result is the path to image which is then hardcoded in the content area. I would prefere the page (+image number) reference.

Thinking out loud:

- Fieldtype like image (drag&drop + select image from local disk) plus a "browse images from system" button which opens a popup/layer like in TinyMCE.

Perhaps not a good idea because the input result is different (images fieldtype store url + description I think, the browse option should store the reference to the original image with an optional possibility to overwrite the original description)

- So better approach I think: Different fieldtype which stores an array of references which can then be accessed like an ordinary image field by $page->myImages->url for example.

While typing this I still think a combination of the two fieldtypes would be nice but surely harder to implement

Okay, I just looked in the database. The image fieldtype doesn't story a unique ID, right? So a reference to a single image (not the url) could become difficult, right?

[ryan]

Sounds like some good ideas for a module. While this isn't a need I come across in my own projects, it seems to line up somewhat with the needs others have mentioned to have a shared image repository, separate from one they'd create with a page.

Okay, I just looked in the database. The image fieldtype doesn't story a unique ID, right? So a reference to a single image (not the url) could become difficult, right?

That's correct. The primary key for an image is its page ID + sort order (if multiple images in the field). Once loaded in memory, images are indexed by their filename. Another image fieldtype could certainly add an ID property to a table easily.

[MadeMyDay]

Ryan, thank you for your thoughts. For the last 2 hours I tried to understand the structure of fieldtypes and inputfields and since I am not the PHP pro I am learning slowly ;-)

So what I think would be a possible approach:

A new module "inputFieldImageBrowsable" or something like that. This module extends the inputFieldImage module with addtional functionalities:

• adds a new column "imageID" or something to the standard field_image table
• adds a new button "browse site images" to the image field
• Configuration:
  parent: the pages where to look for images (like a "media" node)
  type: file extensions to look for
  more things later (search by, more fields for each image, only landscape/portrait etc.)
• button opens fancybox with grid/list view of the images (with url as "data", see below) found in [parent]
• possible to browse through pages via InputfieldPageListSelect
• selection of one or more images by clicking
• submit closes fancybox and shows the images
• The original extended fields (like description) get copied, but are overwritable
• images get new entry in table, but instead of url in field "data" only a reference to the id of the original image is stored (INT).

For that approach also the page render function (?) needs to be extended and has to check the data (if INT use url of original image), so $image->url doesn't output the id but the url of the referenced image. Also the render input has to be extended for displaying the referenced images which then can be mixed with uploaded images.

I think the same module could also handle ordinary files (also makes sense: Think of document management for manuals which are either added for a single page but can also be referenced on other pages).

Why all that? Well, pretty simple: With that approach you could easily change images and files site-wide without changing every single page only by changing the original file. And I think the possibility of mixing uploaded and referenced files in one field would be an exclusive feature compared to other systems

Sounds reasonable?

OT: Edit on Chrome/Mac messes something up in this forum (cannot use "full editor" either, but luckily "save" works ;-) )

[alanfluff]

@MadeMyDay I'll come clean and say I scrolled past most of the conversation there between you and Ryan.

Also I know less than 1/1000th of a percent about this compared to Ryan; literally, so apologies if this is useless, but, it sounded as if this might be of some interest to you perhaps: https://github.com/N...oll/ManageFiles. I modified a copy of this slightly to:


# add permission 'managefiles' so this permission may be granted to user roles
# re-named columns and swapped around a little
# added 'description' so not just getting file name

I've not uploaded it to github yet as I am a total newb, but if you want a copy then just say.

[MadeMyDay]

Hi Alan, I know the file manager. But this is another scope. What I want to achieve is a combination of uploadable files on a page and the selection of already uploaded files on other pages.

Let's take the example page of Ryan (the one with the skyscrapers). Here every skyscraper has one or more images which could be shown on other pages (architects) by creating many to many relations, which works great. But think of other kind of pages like press releases where you want to show only specific images which are already uploaded somewhere. At the moment you can either upload them again for that specific page or you know on which pages on which position they are and include them by hand with a selector. What I want to achieve is that you have the possibility to select single images from other pages by referencing them without duplicates. So if for example a skyscraper image is changed (perhaps of copyright problems) all images referencing this image are also changed.

With that the necessity of a media database is obsolete, because you can easily build it with pages. Or you don't build it and use all images/files site-wide as your media source.

[alanfluff]

I understand I too love DRY (don't repeat yourself) data and would also not want duplicated images.

You likely know the following but just in case not, right now with Manage Files module installed I am able to (with a second tab open, so less than ideal) scroll to find the image I want in the Files page (that's installed by Manage Files module), see the page it's on and back on my first tab as I am editing copy in a TinyMCE textarea, click

the Image icon > images on page (drop down) > change the page from where I am to 'About us' > and select an image from there; then insert and re-size etc.

This keeps my data/images DRY and allows me to use images from any page on the page I'm editing.

This is not exactly what you were looking for I think, but just in case it helped at all I thought I'd note it.

[apeisa]

Alan, that is pretty much different thing. Here it is not about putting images into TinyMCE (it just saves img tag with right src attribute), but putting images (or files) to image field as a reference.

[MadeMyDay]

Exactly. What do you think Atti? Reasonable, possible?

[apeisa]

Reasonable and possible for sure, I also like the thinking you have on this. I haven't had the need myself, but surely that would allow more flexible files management. I would probably add small search box there also (on top of the page tree browsing). But I think there are quite a bit work on this and I also think that this is not needed on most sites, so not the first feature on my wishlist.

One thing to consider is what removing the original image does for the references? Does those references get deleted too? Or does it copy the image for one reference and that will be the official home then?

[alanfluff]

Oops, serves me right for skimming instead of reading, sorry folks.

[ryan]

MadeMyDay is on to some good ideas and things to think about for future upgrades in the images module. I think the primary benefit is in the shared image repository, as mentioned. This is something that my own sites rarely call for, but others have indicated interest in a common image repository. So this seems like a potentially nice approach to think about for the future.

[MadeMyDay]

Thanks Ryan!

Some questions regarding this module:

• Is it possible to define a database schema of an inputfield "on the fly"? Say we have a configuration option for additional fields and I add another field ("title" for example) for one particular field (e.g. "myImage"). Does PW create this database column on first call or how can this be done?
• (also answer to Atti): I think if a referenced image/file is deleted the reference should also be deleted (with a once showed note). Reasonable?
• Are there some docs showing how to start such a project? I am a bit lost I think first I should duplicate the image inputfield (+ fieldtype, right?) and try to create references first. Given that (hopefully) I would have to "hack" into the code where the page object is created, so a $image->title will become possible. How is this done usually?

Thanks in advance!

Marc

[ryan]

Is it possible to define a database schema of an inputfield "on the fly"? Say we have a configuration option for additional fields and I add another field ("title" for example) for one particular field (e.g. "myImage"). Does PW create this database column on first call or how can this be done?

Inputfields are just the input widget (no schema here), whereas Fieldtypes are the data format and storage (schema). For the most part, the schema of fieldtypes does not change from when it was created. The only exception is multi-language fieldtypes, which add new columns when a new language is added. For stuff that is more likely to change (like individual field settings) PW JSON encodes them in the 'fields' table. But this should only be used for things that don't need to be normalized or searchable.

Are there some docs showing how to start such a project? I am a bit lost I think first I should duplicate the image inputfield (+ fieldtype, right?) and try to create references first. Given that (hopefully) I would have to "hack" into the code where the page object is created, so a $image->title will become possible. How is this done usually?

I think that the best starting point for a Fieldtype/Inputfield is the MapMarker fieldtype, which I made specifically for this purpose (as a well commented demonstration). I'm also here to assist in any way I can and guide you through it as you go.

Admittedly, I'm not yet sure how I'd approach a fieldtype that does what you are wanting it to do, so not yet in a good spot to identify the next step on that. But I think part of that is that I can't yet see how it would work to the user. A good place to start might be to mock it up. That would mean to show how it would look or work on the front end. These kind of mock-ups help the direction become more apparent.

[MadeMyDay]

Hi Ryan,

Inputfields are just the input widget (no schema here), whereas Fieldtypes are the data format and storage (schema). For the most part, the schema of fieldtypes does not change from when it was created. The only exception is multi-language fieldtypes, which add new columns when a new language is added.

Ah, okay. Sorry for mixing this up.

For stuff that is more likely to change (like individual field settings) PW JSON encodes them in the 'fields' table. But this should only be used for things that don't need to be normalized or searchable.

Okay, since in the end the images/files should be searchable (as well as the fields added to it) I think these columns could be generated when a new field configuration is saved. But this is later on the roadmap ;-)

I think that the best starting point for a Fieldtype/Inputfield is the MapMarker fieldtype, which I made specifically for this purpose (as a well commented demonstration). I'm also here to assist in any way I can and guide you through it as you go.

yes, this looks helpful. Also Atti's redirect module is a good starting point for module settings.

Admittedly, I'm not yet sure how I'd approach a fieldtype that does what you are wanting it to do, so not yet in a good spot to identify the next step on that. But I think part of that is that I can't yet see how it would work to the user. A good place to start might be to mock it up. That would mean to show how it would look or work on the front end. These kind of mock-ups help the direction become more apparent.

I'll put something together ;-)

[MadeMyDay]

So here we go:

http://siebennull.com/PWfileReference/

I hope it gets clearer ;-)

[apeisa]

Very clean UI thinking there, I like it.

[ryan]

Very nice! I think that really showed it well. A very well put together presentation there too. I don't yet have a clear sense of how something like this might be implemented. I'm not sure this is something that can be implemented purely as a module, because the core assumes that files on a page are owned by the page. For instance, when you delete a page, it deletes all the files on the page. When you remove an image from a page, it deletes the image file when you save. But it goes beyond that (primarily in the core PagefilesManager, Pagefiles, Pageimages, Pagefile, and Pageimage classes). So the considerations would stretch pretty far beyond just the module.

The only way I can think of to bypass that is to actually maintain a blank placeholder image file as the actual reference. The placeholder filename would be in some format where it could be identified as a reference, perhaps something like: page[id]-[fieldname]-[filename].jpg. Using that method, the core could continue to do what it does. When it deletes the image, it deletes the reference file rather than the original image. But when outputFormatting is on, the module would know to convert the images in that specific format to the one that is referenced. Still a bit complicated, but just thinking out loud how something like this might be accomplished, and this might be a way.

[MadeMyDay]

Hi Ryan,

thanks for your thoughts.

I'm not sure this is something that can be implemented purely as a module, because the core assumes that files on a page are owned by the page. For instance, when you delete a page, it deletes all the files on the page. When you remove an image from a page, it deletes the image file when you save.

Well, as said above: When you remove an original, the references are gone, too. No problem with that. I would use a "media"-node with several pages under it, so it is clear that if I delete an item from the database it is gone. Customers also can be teached to understand that.

But it goes beyond that (primarily in the core PagefilesManager, Pagefiles, Pageimages, Pagefile, and Pageimage classes). So the considerations would stretch pretty far beyond just the module.
The only way I can think of to bypass that is to actually maintain a blank placeholder image file as the actual reference. The placeholder filename would be in some format where it could be identified as a reference, perhaps something like: page[id]-[fieldname]-[filename].jpg. Using that method, the core could continue to do what it does. When it deletes the image, it deletes the reference file rather than the original image. But when outputFormatting is on, the module would know to convert the images in that specific format to the one that is referenced. Still a bit complicated, but just thinking out loud how something like this might be accomplished, and this might be a way.

Yeah, this is what I tried to describe above. I think it would be sufficient to add an "id" column to the images/files (always have files in mind, why not treat them the same). And then just put the id of the referenced file in the "data" column. The outputFormatting has "only" to check if the data is a number (INT) and if so, just fetch the original/referenced data, could be a global function fetchOriginalFile() for example. If the original doesn't exist, the output does nothing, the inputField would render a message once (referenced file deleted [x] ). So I - from my noob point of view - think that extending the file/image table with an id column as well as extending the involved classes by a

if (is_int(image['data']) image['data'] = fetchOriginal(image['data']);

could work (pseudocode). But of course I don't know the internals of PW (yet).

I think a page[id]-[fieldname]-[filename].jpg looks a bit like a workaround, which is harder to extend. With the id approach I think it could be also easier to extend the file fields with more fields like title, tags and so on.

I am aware that PW usually encourages me to use pages for that, but especially the image upload function is so nice that I would rather use that