Common system path for images

[ragnarokkr]

Hi everyone. A lot time not writing here but periodically checking for the nice updates.

I'm facing a problem and not able to figure out how to solve it easily  ?  (admitedly that something in programming is easy ?).

I'm trying to implement featured and gallery fields for generic post. My problem is that I need to have the Inputfield reading/writing the images from/to a system folder rather than a page. Reason of that is that:

1. customer stressed me out about the need to have a WordPress-ish ? central folder for images;
2. if referencing images from a page, possible future changes to the source page will change accordingly all images src link, breaking everything (and I'm trying to keep the backend as lighter as possibile by not fill it with modules which keep track of this and that at every change).

I'm actually using the great ImageReference module, but I'm still facing some issues I already exposed on its GitHub repo, which I'll try to summarize here:

• image preview not (yet) responsive in edit page, or at least in my case it doesn't work as (I) expected;
• no scrolling in image selection (widget expans a lot especially if the container is narrow);
• no description available for the uploaded images.

What I would like to have is the power of the default FieldtypeImage combined to the huge range of choices ImageReference gives out of the box, but from what I did understand the author is not interested into merging the things.

All this brings me to the final question, which is:

since I actually cannot afford to spend a lot of time reinventing the wheel, and is low-budget work, is there a way to hook some event from the default FieldtypeImage right before it uploads or reads the file from the page's folder, in a way I can modify the path by routing it to a folder of my choice?

I hope I've been able to make clear my thought ?

 

[BitPoet]

Have given Media Library a look?

[ragnarokkr]

Thanks @BitPoet. Yes I did already look at it. That's an interesting module but unfortunately isn't what I'm looking for because:

• I do need a separate field and not something bounded into the text editor;
• I do need a persistent image file path (not changing with the modification of the source)

Until now what I did find that fits mostly to the needs it's the ImageReference module, but it still lack of the needs I have ?

[BitPoet]

2 hours ago, ragnarokkr said:

Until now what I did find that fits mostly to the needs it's the ImageReference module, but it still lack of the needs I have

I was thinking of combining the two. Have a toplevel Media Library somewhere and let ImageReference pull its images from that. Though I'm not familiar enough with the latter to judge if that would be a working solution.

[gmclelland]

I haven't tried it yet, but https://github.com/mr-fan/AutoImagePages might help?

Related discussion:

 

[gebeer]

7 hours ago, BitPoet said:

I was thinking of combining the two. Have a toplevel Media Library somewhere and let ImageReference pull its images from that. Though I'm not familiar enough with the latter to judge if that would be a working solution.

With Image Reference you can have all images on one page (that can be hidden in the tree). Then you set the ImageReference input field to pull images only from that page.

On 2/3/2020 at 12:41 AM, ragnarokkr said:

• image preview not (yet) responsive in edit page, or at least in my case it doesn't work as (I) expected;
• no scrolling in image selection (widget expans a lot especially if the container is narrow);
• no description available for the uploaded images.

Please note that I already have pushed a fix 2 days ago for the responsive issue you posted on GH.
The scrolling you are talking about is really only needed for rare edge cases like yours where the ImageRefenrence input field in the page edit screen is very narrow. Please understand that I will not cater for that edge case. You might want to rethink the layout of your gallery input in the page edit screen.
If you need descriptions for your images, you can reference them from a hidden page (like mentioned above) instead of from a folder. If someone tries to remove an image from that page and that image is still being referenced somewhere else, the module will give a warning and will not allow to remove the image before all references to it were deleted. So this option could be a solution to your use case.

[ragnarokkr]

16 hours ago, BitPoet said:

I was thinking of combining the two. Have a toplevel Media Library somewhere and let ImageReference pull its images from that. Though I'm not familiar enough with the latter to judge if that would be a working solution.

@BitPoet One of my needs is to have a persistent system path, regardless the page tree structure, so the page as media folder isn't a viable solution. ?

14 hours ago, gmclelland said:

I haven't tried it yet, but https://github.com/mr-fan/AutoImagePages might help?

@gmclelland Thanks. It still relay on pages to work, which is something not usefull in my case ?

8 hours ago, gebeer said:

With Image Reference you can have all images on one page (that can be hidden in the tree). Then you set the ImageReference input field to pull images only from that page.

@gebeer As said, I need a system folder as a source in order to have a persistent and common path regardless the changes an admin could do in future to the page tree, so the one page isn't a viable solution in my case.

8 hours ago, gebeer said:

Please note that I already have pushed a fix 2 days ago for the responsive issue you posted on GH.
The scrolling you are talking about is really only needed for rare edge cases like yours where the ImageRefenrence input field in the page edit screen is very narrow. Please understand that I will not cater for that edge case. You might want to rethink the layout of your gallery input in the page edit screen.
If you need descriptions for your images, you can reference them from a hidden page (like mentioned above) instead of from a folder. If someone tries to remove an image from that page and that image is still being referenced somewhere else, the module will give a warning and will not allow to remove the image before all references to it were deleted. So this option could be a solution to your use case.

I know, I already commented the fix. You did a great work with that but as you said, mine is an edge case. Often the admin panel will be accessed on mobile devices and the narrow layout isn't something I can modify. As you can see, even with less than 10 images (and that's just a test, the production version expects thousands pages, with minimum one image per page) it becomes faster messy without a scrollable option. You can easily imagine how hard it will be on a mobile device.

I know my case is very edge-case and I'm figuring out if there is a way to merge the already good out-of-the-box Image field functionalities with yours or similiar module, but my knowledge of PW core is very poor and is low budget work so I cannot spend too much time in reinventing the wheel.

[gebeer]

19 hours ago, ragnarokkr said:

As said, I need a system folder as a source in order to have a persistent and common path regardless the changes an admin could do in future to the page tree, so the one page isn't a viable solution in my case.

Just an idea:  you could hide the image page from the page tree in the admin area so that users with certain roles cannot mess with it. Some code examples in this thread.
EDIT: that would give you your persistent and common path under /site/assets/files/{imagepageID}/

Edited February 6, 2020 by gebeer

[ragnarokkr]

Yes I could hide the page but I need a solution that keep detached the source path from the CMS page management logic. Anyway as I said this is a low budget project, and I really have no time to spend in "artistic" solutions just to reinvent the wheel. I just moved back to WordPress ? and that's it.

Honestly, I like the idea of the images following their own page because it guarantees a good degree of integrity with image links and the related page, but I also think it introduces a level of redundancy which can become really detrimental at an high level of managing (I'm thinking about - not so edge - cases where thousands pages have to handle more than 1 image common to each one) and I really think that an out-of-the-box system to handle this case via Image field should be mandatory for a CMS like PW. Nothing very complex, just some sort of merge of Image field's and ImageReference's logics to offer the power of the Image options (sizing, cropping, min/max sizes, etc) with the options of different sources. The rest should just be hooks, the developers could register to extend the functionalities.

Anyway, thanks to everyone for your time.

[gebeer]

53 minutes ago, ragnarokkr said:

I just moved back to WordPress

Sad to hear that. But can understand your frustration. People coming from WP are used to have new functionality installed with one click.

 

54 minutes ago, ragnarokkr said:

I really think that an out-of-the-box system to handle this case via Image field should be mandatory for a CMS like PW

PW just uses a different approach here. And there are custom modules like Media Manager or ImageReference that can do what you need.

 

55 minutes ago, ragnarokkr said:

just some sort of merge of Image field's and ImageReference's logics to offer the power of the Image options (sizing, cropping, min/max sizes, etc) with the options of different sources

That is exactly what ImageReference aims to do. I am sorry that it doesn't cater for all of your needs (yet), like descriptions for images from folders.

59 minutes ago, ragnarokkr said:

The rest should just be hooks, the developers could register to extend the functionalities.

That would be what I meant with hiding the image page in the page tree. The link I provided contains code for such hooks. If you don't know how to put a hook together for your exact use case then describe the problem and I am sure someone will help you out here in the forums.

[Macrura]

@ragnarokkr,

i've read a little of this thread and am wondering if you're aware you can set a page to be a system page and then it is not going to be deleted.

I don't see the difference between using a page in the tree for storing images (or a page with children) vs. a folder.

Either one can be deleted.

But setting a page as System, Non-deletable and locked ID, name, template, parent (status not removeable via API) is probably even more solid than a folder.

[gmclelland]

So it sounds like you are wanting the ability to select a file from an predefined directory?  Then the user can select the file using some kind of file browser where you can drill down to select the file you want?

It would be cool if someone made another module that can either extend the core imagefield or create a new fieldtype to allow for different sources to be added via additional modules?

I've used something like this before in Drupal with the https://www.drupal.org/project/filefield_sources module.  You can see all the modules that integrate with it at https://www.drupal.org/search/site/filefield sources.

In the screenshot below, you can see the different toggle links/tabs that are added: Upload, File Browser, Reference existing, Remote URL.  Each additional module can add more toggle links to change the input that is used.  Sources are configured per field in the field settings.

If we had a module like that, then we could create an another integrated module that adds a "File browser" source link/tab that uses an input similar to the "Page List Select Multiple" input field type from the core Page Reference module, but instead of pages show/select files and folders?

Maybe the input could look something like this??  Taken from PageListImage module at 

 

 

There is also already a module to select files, but maybe it could be modified to add a new inputfield type similar to image above?

Or maybe you could have a module like https://www.drupal.org/project/imce and  https://www.drupal.org/project/imce_filefield that just adds a "Open File Browser" link to the image field that opens IMCE or similar to browse a file system?  There is also https://www.drupal.org/project/visual_select_file that has a slightly different UI.

I know this isn't a solution, but these are all rough ideas of me thinking out loud in case any one wants to run with it?

 

[ragnarokkr]

@gebeer I moved away from WordPress years ago and the very first (and only) choice for this project back then was PW. I used and loved it at very first time and it really doesn't give me any pain its way to handle images. But now the customer wanna update and expand everything, and since his requirements for media managing are quite mandatory and an upgrade is required I'm watching for a solution which fits requirements and low-budget needs. I would never came back to WP if PW had this kind of field out-of-the-box.

@Macrura Pages (system, locked, hidden, abstract or in parallel dimension) are still pages, with their path on the system which isn't decoupled by the CMS managing (nothing I can decide before and keep in future if deep changes are made). It's still a relative path to a CMS hierarchy of folders always affectable by changes made by the superuser. If I decide in future to implement any kind of system to furtherly decouple the media archive from the CMS itself (for example, by implementing symbolic linking via virtual FS on another server) or implement other kind of things to preserve integrity of media archive (like, just for example, some kind of remote backup process) everything will always relay on a path which could change through the time by external conditions, breaking the decoupling idea of set-and-forget settings and, more seriously, breaking all image links (imagine to fix 1 or more image links per page per thousands pages).

@gmclelland Yes you got the point. A powerful CMS like ProcessWire that points to challenge the big ones on the market (and it can easily do that) should think about a solution out-of-the-box for media managing similiar to the one offered by the competitors. I'm not saying it has to provide n-thousands functionalities probably usefull for the 0.1% of the users, but a basic media library with the moreover already provided functionalities should be a must. (The CMS often is used for blogs and websites where presence of images is almost a constant, so the case is more than just a edge case IMHO.) For everything else there are hooks and plenty of space for developers to implement gazillions of features not basically required.

I've no knowledge in PW core and no time to spend in research how to take this and that from here and there just to put together something working for my case in front of the low-budget situation, so I have to relay on the cheaper solution with the most complete offer, and actually WP is sadly the answer for this case. I don't like the choice but there's no a valid alternative solution. (I also took in account Ghost and Strapi - which is the most similiar to PW for Node.js, but both lacks of media management too.) 

That's it. If I will have spare time to go deep into PW core and find furthermore info about extending core Image module in order to add these functionalities, I'll do it with pleasure.

[kongondo]

35 minutes ago, ragnarokkr said:

something working for my case in front of the low-budget situation, so I have to relay on the cheaper solution with the most complete offer, and actually WP is sadly the answer for this case.

Maybe you could consider Media Manager ??