Three suggestions related to file manager and file sets in 5.7.x
Permalink
It would be great if...
- files in file sets were sortable, at least by file name or title (asc/desc), not only by drag & drop. If there is a big number of files, it's a pain to sort them manually.
- the file manager would get an adjustable pagination to enable setting the number of files displayed per page (10, 50, 100, 500, all).
- files could be assigned to file sets right after the upload process, such as in Concrete5.6.
Thank you,
Michael
- files in file sets were sortable, at least by file name or title (asc/desc), not only by drag & drop. If there is a big number of files, it's a pain to sort them manually.
- the file manager would get an adjustable pagination to enable setting the number of files displayed per page (10, 50, 100, 500, all).
- files could be assigned to file sets right after the upload process, such as in Concrete5.6.
Thank you,
Michael
Good news, thank you!
I would suggest you to create github issues for the two first they are simple enough to be done by some random passing dev :) (like me :) )
Now, knowing that andrew is hacking the file manager, I'd rather wait him do so and hack on the top of it, so I will wait a comit stating that he did before I dig in :)
Now, knowing that andrew is hacking the file manager, I'd rather wait him do so and hack on the top of it, so I will wait a comit stating that he did before I dig in :)
Actually, now that I think about it, I will probably have to dig in the core to integrate a part of my addons in it :/
I will create your github issue and check in the next month probably.
I will create your github issue and check in the next month probably.
Thanks a lot, Florian!
BTW you can already do the sorting in "Customize results"
Unfortunately this is not true for file sets. Having a lot of images in file sets, a way to sort files easily would be very welcome!
Well we used to be able to filter by set in 5.6, but I guess this needs to be re-installed too.
While it's nice to be able to sort a small amount of files in a file set (images, for example) by drag and drop, at least for me it's much more important to sort files by filename, title or date, in case there is a large number of files.
It's no fun to sort 60 images by drag and drop, if you just want to have them sorted by filename (title). I use to always rename files in a way that they can be sorted alphabetically in a reasonable way, depending on what they are used for. So there is always a need for me to have an option to sort them alphabetically in file sets. Of course the whole thing only makes sense, if galleries assume that file sequence.
BTW this has never been possible for files in file sets in Concrete5.6.
It's no fun to sort 60 images by drag and drop, if you just want to have them sorted by filename (title). I use to always rename files in a way that they can be sorted alphabetically in a reasonable way, depending on what they are used for. So there is always a need for me to have an option to sort them alphabetically in file sets. Of course the whole thing only makes sense, if galleries assume that file sequence.
BTW this has never been possible for files in file sets in Concrete5.6.
Well, I can see a simple way to do it, so I might take that too.
It seems that no much effort had been done on the file manager (https://github.com/concrete5/concrete5-5.7.0/issues/537... ), so give me a few weeks and I'll see what I can do.
It seems that no much effort had been done on the file manager (https://github.com/concrete5/concrete5-5.7.0/issues/537... ), so give me a few weeks and I'll see what I can do.
That sounds great!
Merci beaucoup!
Merci beaucoup!
Thank you, adding these features will be useful.
done: The fileset is now sortable by title, filename, type, or date.
(If you need more tell me now before the merge is done)
https://github.com/concrete5/concrete5-5.7.0/pull/1746...
(If you need more tell me now before the merge is done)
https://github.com/concrete5/concrete5-5.7.0/pull/1746...
That's just great. Thank you!
BTW, i hope, the file set page will NOT get a pagination now or in the future, otherwise sorting would only affect the current page...
Thanks again and - Bonne Année!
BTW, i hope, the file set page will NOT get a pagination now or in the future, otherwise sorting would only affect the current page...
Thanks again and - Bonne Année!
I don't think it is in the plan (no pagination in my pull request at least).
Anyway, those things can be worked up at that time :)
Happy new year too (btw I am in China, so I am already in that year, this was somehow a message from the future Marty! ;) )
Anyway, those things can be worked up at that time :)
Happy new year too (btw I am in China, so I am already in that year, this was somehow a message from the future Marty! ;) )
done your second item on the list (pagination control)
https://github.com/concrete5/concrete5-5.7.0/pull/1748...
(That was seriously trivial actually).
https://github.com/concrete5/concrete5-5.7.0/pull/1748...
(That was seriously trivial actually).
Wow, that's cool. Will we really see all that nice stuff in 5.7.4?
not sure, it will depend on where andrew will merge it… I already have 5 merge requests waiting in queue (and that's only me). Although I guess it is related to the end year break :/
btw, since andrew already assigned himself the last of your items, I am not sure I will work on it yet, I have a few stuff to do on my own here plus he will be a lot more productive on that since he knows the code better…
Will see how the rest goes.
btw, since andrew already assigned himself the last of your items, I am not sure I will work on it yet, I have a few stuff to do on my own here plus he will be a lot more productive on that since he knows the code better…
Will see how the rest goes.
Alright!!!
I completey refactored the file manager menu, added the upload target and more, so that complete all the requests here :)
Now I am gonna need you guys support so that andrew/korvin merge this in :)
Pull request:https://github.com/concrete5/concrete5-5.7.0/pull/1762...
I completey refactored the file manager menu, added the upload target and more, so that complete all the requests here :)
Now I am gonna need you guys support so that andrew/korvin merge this in :)
Pull request:https://github.com/concrete5/concrete5-5.7.0/pull/1762...
Great work on the file manager! I really hope they will merge your contribution.
Thank you!
How can we support that pull request?
Thank you!
How can we support that pull request?
How do you like this in comparison to the 5.6 dialog? How does it compare? Do you think it's as efficient or as understandable? How about the "Uploaded/Selected" control when you've neither uploaded nor selected something?
FYI: this pull request is held up mostly because it's a rather large change under the hood.
FYI: this pull request is held up mostly because it's a rather large change under the hood.
- How about the "Uploaded/Selected" control when you've neither uploaded nor selected something?
I'm now seeing that point!
The assignment of files to filesets, as well as the creation of new filesets if desired, should have to be done during the upload process, respectively right after the last image has been successfully been uploaded. Actually as 5.6 did that. But in case one forgets to do so, it would be great to have a second chance by something like a "Recently Uploaded" link, to filter the latest uploaded files, to be able to assign them to a fileset later on (just another filter, like "files in no filesets").
I'm now seeing that point!
The assignment of files to filesets, as well as the creation of new filesets if desired, should have to be done during the upload process, respectively right after the last image has been successfully been uploaded. Actually as 5.6 did that. But in case one forgets to do so, it would be great to have a second chance by something like a "Recently Uploaded" link, to filter the latest uploaded files, to be able to assign them to a fileset later on (just another filter, like "files in no filesets").
Currently (in the pull request), the bulk menu is disabled (as before) when nothing is selected or uploaded.
Each button becomes accessible (enabled) only if they are relevant. If you think that is best, I can definitely hide them completely if not relevant (that is pretty easy), but I think it is better to let them visible but disabled to know-they-are-here.
Totally open to suggestions here.
Each button becomes accessible (enabled) only if they are relevant. If you think that is best, I can definitely hide them completely if not relevant (that is pretty easy), but I think it is better to let them visible but disabled to know-they-are-here.
Totally open to suggestions here.
Also for you to know without to read all the thread of the proposed pull request, mainly this pull request brings the possibility to have the menus modified (extended) by the application or packages.
The new workflow proposed in this pull request is the following:
- In case nothing is selected or uploaded, the bulk menu is not accessible (just like before)
- In case you select something the bulk menu becomes accessible (the uploaded target is disabled unless something is uploaded), and the selected button is selected.
- When you upload something (drag&drop or click on the link), then the uploaded button is selected and the bulk menu is then opened at the end of the upload.
You have then access to all the bulk menu actions onto that new set of files.
- If you select something else, then the "selected" target becomes selected again (but you can still click on the uploaded target if you wish later on).
- The uploaded files are remembered as long as you don't refresh the page (or re-upload something else, in that case the new files becomes the target).
My point is that it lets you add the filesets doing properties whenever you want after uploading those. Plus it does not throw a big dialog at you. It lets you do it *if* you want to do it (and whenever you want).
Another added value (under the hood) is that all actions developed for the bulk menu (or the context menu) becomes instantly accessible for all targets at no additional cost.
The other addition is under the hood, with the new architecture, all actions are now stored in a helper, and the modification from a package does not involve JS at all. (Simply a $fm->addItem($item)). The point being that I personally believe addon devs should have as few js to code as possible (js is always a tricky thing when it comes to browser compat).
And the last thing is the icons, that I added, and that andrew want to get rid of (no sweat here, if you guys think it is better, I'll remove them in one shot).
I think that is all there.
The new workflow proposed in this pull request is the following:
- In case nothing is selected or uploaded, the bulk menu is not accessible (just like before)
- In case you select something the bulk menu becomes accessible (the uploaded target is disabled unless something is uploaded), and the selected button is selected.
- When you upload something (drag&drop or click on the link), then the uploaded button is selected and the bulk menu is then opened at the end of the upload.
You have then access to all the bulk menu actions onto that new set of files.
- If you select something else, then the "selected" target becomes selected again (but you can still click on the uploaded target if you wish later on).
- The uploaded files are remembered as long as you don't refresh the page (or re-upload something else, in that case the new files becomes the target).
My point is that it lets you add the filesets doing properties whenever you want after uploading those. Plus it does not throw a big dialog at you. It lets you do it *if* you want to do it (and whenever you want).
Another added value (under the hood) is that all actions developed for the bulk menu (or the context menu) becomes instantly accessible for all targets at no additional cost.
The other addition is under the hood, with the new architecture, all actions are now stored in a helper, and the modification from a package does not involve JS at all. (Simply a $fm->addItem($item)). The point being that I personally believe addon devs should have as few js to code as possible (js is always a tricky thing when it comes to browser compat).
And the last thing is the icons, that I added, and that andrew want to get rid of (no sweat here, if you guys think it is better, I'll remove them in one shot).
I think that is all there.
Thank you for the detailed information, it's good to know how it exactly works!
So, when the upload is done, the window with the progress bar disappears and then the uploaded button is selected and the bulk menu is opened.
This looks like a pretty smooth workflow for editors. It seems that Andrew did not know about how it works in detail, when he asked "How about the "Uploaded/Selected" control when you've neither uploaded nor selected something".
As for the icons, personally i like them. For me, it's not the question "icons or text" in favor of design, but whether icons make more sense or text or both. For example, "Advanced Toolbar", an add-on that i like a lot, doesn't ship with icons, because text makes more sense in this case, while the icons of the main toolbar are quite understandable even without additional text.
I think, the decision of using text or icons should be mainly based on functionality and user-friendliness. In case of your menus, i see the presence of both as a good solution.
So, when the upload is done, the window with the progress bar disappears and then the uploaded button is selected and the bulk menu is opened.
This looks like a pretty smooth workflow for editors. It seems that Andrew did not know about how it works in detail, when he asked "How about the "Uploaded/Selected" control when you've neither uploaded nor selected something".
As for the icons, personally i like them. For me, it's not the question "icons or text" in favor of design, but whether icons make more sense or text or both. For example, "Advanced Toolbar", an add-on that i like a lot, doesn't ship with icons, because text makes more sense in this case, while the icons of the main toolbar are quite understandable even without additional text.
I think, the decision of using text or icons should be mainly based on functionality and user-friendliness. In case of your menus, i see the presence of both as a good solution.
I understand what "Uploaded" and "Selected" means. I didn't understand why I was seeing those selections when I had neither uploaded something nor selected something. I'm also concerned that half the things that show up in that menu (delete, rescan, download) make absolutely no sense in the context of files that I've just uploaded.
Well, I guess I can hide the button if not relevant (instead of just disabling it).
Rescan aside I do think that delete and download make sense :
- Download: check what I just uploaded (just in case)
- Delete : undo that upload I actually messed up
If you were as clumsy as I am, you would have wished to have those two menus for a long time :)
Rescan aside I do think that delete and download make sense :
- Download: check what I just uploaded (just in case)
- Delete : undo that upload I actually messed up
If you were as clumsy as I am, you would have wished to have those two menus for a long time :)
"files could be assigned to file sets right after the upload process, such as in Concrete5.6."
This feature is coming in 5.7.4.
https://github.com/concrete5/concrete5-5.7.0/issues/537...