Filebrowser: customizable filters for individual folders

[Tata]

However, I noticed a problem: what to do, if the user configured the four folders to be (partially) the same?

That's good point.
IMO using some sort of filter would ne appropriate. Especially, if a user makes and names a folder depending on its content. E.g. a folder with all necessary files concerning his personal dokuments, photosatc. which shall stay e.g. downloadable. In this case JPGs, PNGs, PDFs, ZIPs would logically saved in e.g. MyData folder. The a filter fot these files shall be available.
But if organizing galleries there would be reasonable subfodlers with events-names. There then only JPGs, PNGs evtl. videos shall be alloewed in these folders.

[cmb]

IMO using some sort of filter would ne appropriate.

We already have a simple filter scheme in place, that can be configured for the four different folders: images, downloads, media and general userfiles. Do you suggest to extend this scheme?

[Tata]

Mybe my explanation and concept was not clearly expressed. I mean a feature that enables to me as the enduser create new subfolders under userfiles and set their very individual filters.
E.g.:
/userfiles
//images
//downloads
//media
//mydata /* containing e.g. my resume.pdf, diploma.png, statement.rtf, portfolio.zip
//holidays
///2013 /* conaining all JPGs and video files of holiday 2013

The option for setting the filter would be nice somevhere within subfolder creation.
But it might be unreadonable much to do. It was just an idea to have e.g. checkboxes to make the filtering mask for each folder.

E.g.:
[ NEW FOLDER NAME ] images[ ] documents [ ] video [ ] sound [ ] archives [ ]
So if a new folder name would be given and chckbox/checkboxes would be checked, all extensions acceptable for a group would automatically be assigned to this very folder.

[cmb]

Ah, I see--thanks for the explanation.

I have to admit that this would be a powerful solution, that would also solve the problem mentioned above. However, I am reluctant to do this for 1.6.2, as that would require substantial modifcations to the filebrowser, which should better be cleaned up first, and we shouldn't delay the release of 1.6.2 not too long as there are some bug fixes pending.

What about putting your suggestion on the roadmap for 1.6.3, and to stick with a simpler solution/workaround for 1.6.2?

[Tata]

Please do it. My very first intention arose from my own needs. I have my private webpage with all above mentioned documents, so if I need to make them accessible to someone, I give him access to a page with wDIR plugin on and he can download them simply. Filering is possible in the plugin as well, but I dont need to filter them on the pages. Also backup and/or update is easier for me, when related documents go into dedicated folder.

[cmb]

I have my private webpage with all above mentioned documents, so if I need to make them accessible to someone, I give him access to a page with wDIR plugin on and he can download them simply. Filering is possible in the plugin as well, but I dont need to filter them on the pages. Also backup and/or update is easier for me, when related documents go into dedicated folder.

ACK. Another reason for having individual filters is to be able to generally group files by topic rather than by file type; on further consideration I'm not even sure, if the three special folders images/, downloads/ and media/ make really sense. Maybe that's just a relict of the past, which could be removed.

I have put your suggestion on the 1.6.3 roadmap.

[cmb]

I have to admit that this would be a powerful solution, that would also solve the problem mentioned above. However, I am reluctant to do this for 1.6.2, as that would require substantial modifcations to the filebrowser, which should better be cleaned up first, and we shouldn't delay the release of 1.6.2 not too long as there are some bug fixes pending.

Unfortunately, there has not be made any progress in cleaning up/refactoring the filebrowser so far. I have explicitely proposed to do that for CMSimple_XH 1.7, and therefore I think it's better to postpone this topic (customizable filters) to XH 1.7 as well.

[Tata]

+1
Better later and properly than immediately and with hidden bugs