Jump to content

File Manager


nikola
 Share

Recommended Posts

It would be nice to have integrated file manager where we could quickly browse images and other media.

For instance, if we have images field in admin, currently we have only option to browse for images from local disk. It would be nice to have another button next to browse button that would call file manager and allow us to select images (or files) located already on the server.

I used elFinder file manager found at http://elrte.org/elfinder before and I think it would be nice if we can see that option integrated in the future.

This is a different approach from what we currently have in choosing image insertation through TinyMCE...

  • Like 1
Link to comment
Share on other sites

That looks to be a really nice file manager they've built there (elFinder), thanks for the link. Perhaps something that could be a nice 3rd party module option to integrate in the future. PW itself is kind of a virtual file system where any given page can act as a directory, so it's very easy to create a structure of pages for storing assets like images for insertion with TinyMCE or the like. But it is true that it's not going to go pull up images outside of PW's file system, so there may be value in having a module like elFinder for some users.

Link to comment
Share on other sites

  • 5 months later...
  • 4 months later...

I think something that allows reusing files on an image field would be useful. Instead of just having a "upload" button on an image field, there could also be a "select" button that would allow you to select a file from the server. Perhaps this browsing could be done with a 3rd party tool. Any solution considered should be able to work for image fields and WYSIWYG.

Drupal's media module allows you to upload any media file and adds it to the "library". Once there you can reuse it on any content page via a "select media" button. Then there is a plugin for ckeditor that allows you to embed media from the library in the body content. So you can use the media files in fields or wysiwyg. From there there is an module that extends the functionality by accepting youtube video urls. So you can add a youtube video to the library and use it wherever you want.

Another CMS that handles media management extremely well is concrete5. Makes it easy to add photos and videos, you can organize them with categories and easily create galleries based on the categories.

ckfinder is another file browser that integrates with ckeditor.

Link to comment
Share on other sites

The thing to remember about PW though is that files uploaded to a page are stored in a folder with that page ID rather than a separate folder structure, making handling them in the current page very simple.

That obviously then adds a few problems to an overall file manager, but I suspect that you would usually know whih page certain images are attached to so it's not that big of a problem.

It is quite a large undertaking though as you'd probably want a decent search feature to find images by page title or by image description as well as other features.

It's also worth noting that you can already insert images from other pages using TinyMCE in PW, so that functionality is already there. Technically you could create a gallery template with just a title and images field and create a structure for storing images in a structured location that way, but as you're already aware you then have the issue of not being able to link to them in an images field.

Lots of things to think about and it's a complicated topic.

Link to comment
Share on other sites

The other really big issue that being able to use images from another page in an image field would introduce is if the page that image was originally from gets deleted, as presumably you'd want to link to the original rather than copy it (although copying it to the current page would certainly get rid of that problem and I can't imagine images getting reused that much really).

Link to comment
Share on other sites

Interesting fact is that after building couple sites, some with lots of images, there's been always a good solutions (image per page) that even without a media manager it just works. The on page files has limits it seems at first, but it has also many pros. People working with me or clients wheren't really asking for something, but saying this is amazingly simple. Drag upload all files, arrange them and the gallery is finished. I find it fascinating that you can actually do pretty much with that system and even without a "real" media manager all the other cms have, which I mostly found akward to use.

  • Like 2
Link to comment
Share on other sites

I'm with you on that Soma. Even on my largest site with 400 pages there are only a few images (maybe 5-10) that actually needed to be re-used elsewhere.

The more I think about file managers the more my head hurts nowadays, but it did seem odd at first coming from MODx's file manager (something hooked up to TinyMCE) but after you get used to it it's far easier this way for most purposes I've found.

  • Like 2
Link to comment
Share on other sites

The request for a media manager has come up a few times here. Once you really get into the ProcessWire frame of mind, a media manager becomes redundant (at least in my opinion). But it's so ingrained in other CMSs that it's understandable why it comes up. In ProcessWire any page can be a media manager, able to share any of it's assets with any other page. Not just from the API, but from the editor (TinyMCE) as well, you can select images or files from other pages. If you need something formal, like a "shared images" page, then you would create that page in your structure and use it specifically for that. Different I know, but also very capable. We will continue to improve the file and image fields to the point where any perceived benefits from a separate file manager would be diminished.

Link to comment
Share on other sites

Maybe I should actually create a site with processwire before making suggestions, seems like I am stuck in the Drupal state of mind still.

I was a long-time MODx user before PW and it does take time to un-learn your previous system.

Moving forward though PW is pretty easy to pick up with the right examples - the people using it have a wide range of programming knowledge and ability. It's always interesting to see what people come up with and gratifying to see them get going with it after asking a few questions here, so if you have any other queries or suggestions please keep them coming.

  • Like 3
Link to comment
Share on other sites

I have always found the dedicated "media library" to get messy after a while and is always confusing clients - It takes the user out of the context of the current page. It’s definitely a legacy of previous CMS systems. I have found the page related media to work far better in the systems I have built since using PW. The only scenario where it might make sense is for a set of shared assets or when you want to restrict a user to use certain media (like for branding or style guides). In this case you could create a dedicated page called assets which will then be accessible when you use the media browser in TinyMCE . Maybe an additional field type could be built that allows you to browse a specified page - call it “Media Browser” - which lets you assign a page that has the media assets. This would appear like the current image field type, apart from when you click “open file” it shows you a list (nice thumbnails) of the available media.

Link to comment
Share on other sites

I was a long-time MODx user before PW and it does take time to un-learn your previous system.

Moving forward though PW is pretty easy to pick up with the right examples - the people using it have a wide range of programming knowledge and ability. It's always interesting to see what people come up with and gratifying to see them get going with it after asking a few questions here, so if you have any other queries or suggestions please keep them coming.

I am starting to notice this, thanks for the encouragement and the continued advice.

Link to comment
Share on other sites

I have always found the dedicated "media library" to get messy after a while and is always confusing clients - It takes the user out of the context of the current page. It’s definitely a legacy of previous CMS systems. I have found the page related media to work far better in the systems I have built since using PW. The only scenario where it might make sense is for a set of shared assets or when you want to restrict a user to use certain media (like for branding or style guides). In this case you could create a dedicated page called assets which will then be accessible when you use the media browser in TinyMCE . Maybe an additional field type could be built that allows you to browse a specified page - call it “Media Browser” - which lets you assign a page that has the media assets. This would appear like the current image field type, apart from when you click “open file” it shows you a list (nice thumbnails) of the available media.

Building on this a bit, how about a field that works like the "related page" field, but for images. So I can reuse an image uploaded on one page's image field in another page's image field. Without having to upload it twice. Sort of like how the TinyMCE plugin allows you to use images from another page in the WYSIWYG, but for fields.

Link to comment
Share on other sites

I think that would be massively complicated in that if you delete the original page it's attached to then that file also gets deleted (each file/image is stored in a folder named with that page's database ID).

Link to comment
Share on other sites

Building on this a bit, how about a field that works like the "related page" field, but for images. So I can reuse an image uploaded on one page's image field in another page's image field.

While it may be okay to do once in awhile, I would avoid structuring your site in a way that requires uploading the same image in multiple places. Instead, pull from the source page via the API and use the image. An example of this would be a site structure like this:

/about/
 /contact/
 /press/
 /history/

Lets say that you want all these pages to have the same header image. Rather than populating a header_image field on each page with the same image, populate it on just your /about/ page and let the others pull from it. Even if all the pages use the same template file, you can achieve it with this:

$image = $page->header_image;
if(!$image) $image = $page->rootParent->header_image;  
if($image) echo "<img src='{$image->url}'>";

The approach here is to give each page the ability to define it's header image, but make it optional. When it's not populated, it grabs the default from the root parent page (/about/). But lets say your structure is a little deeper than that:

/about/
 /contact/
/directions/
 /press/
 /history/

In that case, you may want to have it inherit the header image from the nearest parent that has it defined. So /about/contact/directions/ would show the header image from /about/contact/ (if it had one) rather than the one from /about/:

$parent = $page;
do {
 $image = $parent->header_image;
 $parent = $parent->parent;
} while(!$image && $parent->id);
if($image) echo "<img src='{$image->url}'>";

There may be other cases outside of the example above where you might have the need of using an image defined on another specific page. In that case, use a page reference field. You might call it header_image_page. It would essentially say "I want to display the header image from that page". This is a little better than a direct file reference because your image will still work even if the source page changes it.

$image = $page->header_image_page->header_image;
if($image) echo "<img src='{$image->url}'>"; 
  • Like 5
Link to comment
Share on other sites

  • 3 years later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...