I require the communities input.
I'm thinking of removing the file manager and adding having a page specifically for uploading images. when you add the images you can other details such s image tag, name etc..
you can then select these images on other pages using auto complete searching for the image tags.
similar to when you upload images to google+
this means though that all images will be saved under one folder.
I will also add a system to remove images no longer listed in the DB and report images that are missing.
What do you think? The file manager is really pain in the neck to make work correctly.
Sounds good, except for the requirements of having them all in one image folder. Would it be possible to also allow for image sub-folders without too much trouble?
Also, selecting an image when needed e.g. on the product edit page, in a description, or wherever, via an autocomplete mechanism might be cumbersome for a user without visual image thumbnails. We have quite a few Opencart websites where the images were provided by 3rd party product suppliers or manufacturers, and quite often they tend to use weird image file names. I am not quite sure whether it would be possible in the autocomplete to show image thumbnails in addition to the names in an autocompleted dropdown list.
Just a few quick thoughts.
Also, selecting an image when needed e.g. on the product edit page, in a description, or wherever, via an autocomplete mechanism might be cumbersome for a user without visual image thumbnails. We have quite a few Opencart websites where the images were provided by 3rd party product suppliers or manufacturers, and quite often they tend to use weird image file names. I am not quite sure whether it would be possible in the autocomplete to show image thumbnails in addition to the names in an autocompleted dropdown list.
Just a few quick thoughts.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Sound good.
Like JNeuhoff says, there should be a folder per category to put the images for that category&products otherwise it will be a great mess + I think such a single folder will take to much time to load.
Removing orphan images and a warning system if an image is missing is also a good thing.
Like JNeuhoff says, there should be a folder per category to put the images for that category&products otherwise it will be a great mess + I think such a single folder will take to much time to load.
Removing orphan images and a warning system if an image is missing is also a good thing.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
at the moment with the file manager you can delete an entire directory and lose the links to a lot of products.
with each image going into the db it means error messages can be shown if the image is linked to a product.
also maybe i can set the system so people can download the original image if they need to.
with each image going into the db it means error messages can be shown if the image is linked to a product.
also maybe i can set the system so people can download the original image if they need to.
OpenCart®
Project Owner & Developer.
I agree, good idea.
If it "self-explores" so as to show subdirectories, then arranging images can continue with minimal fuss. With too many images remembering or second-guessing what to start with for autocompletion, without resorting to a directly listing locally or in ftp by names or timestamps, would tend to be frustrating, but the flip side is that a drop-down selector won't do much good with too many. A possible compromise would be to add to it an "explorer" box for reference, for a selectably name or timestamp roster of files, similar to what the ckfinder/kcfinder passwordable upload/download modules can do for uploading to a specified target directory and even subdirectories there -- but in their instances cannot be aimed at an exisiting OC directory (the workaround invoking an Apache trick to make a directory for Apache to use as a springboard into the real tree does NOT work). Whatever else ckfinder/kcfinder might do, that aspect would not want to be incorporated as-is.
Agree on orphans -- auto-cull and auto-notify would both be helpful.
Agree on thumbnails, the minor additional time for those to load would be well worth the wait.
Suggest big enough box, resizeable or not. Heavily populated undersize non-resizeable boxes are tedious, too few items can be seen at a time.
For many situations an increase in speed would be substantially helpful, even one file at a time.
For most situations moving several to many files at once would be helpful. The html based single-file limitation can be gotten around. To move massive numbers of files would still invite using ftp. For images ftp is readily done, taking pains to aim (clients) at the correct directory. For downloadable (/download/) files ftp is not readily done, since ftp would bypass hashing their names, unless an Apache or other md5 sort of hashing could be done off-site and OC would honor that along with on-board hashes required to authorize the prepaid downloads -- dunno, maybe more of a headache than it's worth.
If it "self-explores" so as to show subdirectories, then arranging images can continue with minimal fuss. With too many images remembering or second-guessing what to start with for autocompletion, without resorting to a directly listing locally or in ftp by names or timestamps, would tend to be frustrating, but the flip side is that a drop-down selector won't do much good with too many. A possible compromise would be to add to it an "explorer" box for reference, for a selectably name or timestamp roster of files, similar to what the ckfinder/kcfinder passwordable upload/download modules can do for uploading to a specified target directory and even subdirectories there -- but in their instances cannot be aimed at an exisiting OC directory (the workaround invoking an Apache trick to make a directory for Apache to use as a springboard into the real tree does NOT work). Whatever else ckfinder/kcfinder might do, that aspect would not want to be incorporated as-is.
Agree on orphans -- auto-cull and auto-notify would both be helpful.
Agree on thumbnails, the minor additional time for those to load would be well worth the wait.
Suggest big enough box, resizeable or not. Heavily populated undersize non-resizeable boxes are tedious, too few items can be seen at a time.
For many situations an increase in speed would be substantially helpful, even one file at a time.
For most situations moving several to many files at once would be helpful. The html based single-file limitation can be gotten around. To move massive numbers of files would still invite using ftp. For images ftp is readily done, taking pains to aim (clients) at the correct directory. For downloadable (/download/) files ftp is not readily done, since ftp would bypass hashing their names, unless an Apache or other md5 sort of hashing could be done off-site and OC would honor that along with on-board hashes required to authorize the prepaid downloads -- dunno, maybe more of a headache than it's worth.
instead of directories you would add tags to the images.
so you can add tags like power tool, drill, dewalt, model no.
and use these keywords in the auto complete
should not be to hard if you have just entered a product that is a dewalt electric drill.
its pretty much how google+ and facebook work.
so you can add tags like power tool, drill, dewalt, model no.
and use these keywords in the auto complete
should not be to hard if you have just entered a product that is a dewalt electric drill.
its pretty much how google+ and facebook work.
OpenCart®
Project Owner & Developer.
I like that approach, ask it what the images are about rather than for the images themselves.
It probably actually is realistic to raise the bar on browser requirements, so that variations in how they render or work anything are held to a manageable level. The newer few IdiotExpress versions and proprietary spinoffs (ArghOnLocation, etc.) can't be ignored but older ones can be ignored and still older are ignored (die, 6, damn it, die, and stay dead). The token system speaks against setting up admin for mobile devices even though some of their browsers now actually work.
Selection of which ckeditor (or comparable other) package to use (or to replace all-new) will probably be a little bit tricky in any event. Now that ckeditor has dropped support for IE7, its own service population among browsers is sailing forward, and since it will make those decisions independently (natch), it could become awkward to incorporate.
Servers are increasingly offering elevated php.exe, fairly few offer selectably the full 5.x range .1 - .5), a few enforce 5.4 or 5.5 (that doesn't work well, upended a few OC), and many still aren't up to 5.3 (which for me has been the sweet spot across the board). it would be nice to require a php.exe threshold for a balance between niceties and silly deprecation halts. But that's not happening.
It probably actually is realistic to raise the bar on browser requirements, so that variations in how they render or work anything are held to a manageable level. The newer few IdiotExpress versions and proprietary spinoffs (ArghOnLocation, etc.) can't be ignored but older ones can be ignored and still older are ignored (die, 6, damn it, die, and stay dead). The token system speaks against setting up admin for mobile devices even though some of their browsers now actually work.
Selection of which ckeditor (or comparable other) package to use (or to replace all-new) will probably be a little bit tricky in any event. Now that ckeditor has dropped support for IE7, its own service population among browsers is sailing forward, and since it will make those decisions independently (natch), it could become awkward to incorporate.
Servers are increasingly offering elevated php.exe, fairly few offer selectably the full 5.x range .1 - .5), a few enforce 5.4 or 5.5 (that doesn't work well, upended a few OC), and many still aren't up to 5.3 (which for me has been the sweet spot across the board). it would be nice to require a php.exe threshold for a balance between niceties and silly deprecation halts. But that's not happening.
I wouldn't see a problem with one folder as long as it does 2 things:
1) It still loads fast when you open the new "file manager"
2) If there's a way to have the images deleted when you delete a product all together. The reason I organize the images now is because there are thousands of images on the server and I like to keep up with the deletion of old images after a product is completely removed.
DL
1) It still loads fast when you open the new "file manager"
2) If there's a way to have the images deleted when you delete a product all together. The reason I organize the images now is because there are thousands of images on the server and I like to keep up with the deletion of old images after a product is completely removed.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
the removal of the file manager is fine as long as the replacement can do a good job in managing the images. Another way you may want to consider would be to have direct image upload at each location, just like how you have the image uploading function done on current opencart.com extensions management. The only con about this is that you won't be able to manage / delete images, but this would definitely speed things up in uploading.
Not sure if this is applicable:
Can the images be saved and served from a cookieless domain?
ie: https://developers.google.com/speed/doc ... es/request
Will there be an easy way to deal with securing images in a multi-store configuration?
Can the images be saved and served from a cookieless domain?
ie: https://developers.google.com/speed/doc ... es/request
Will there be an easy way to deal with securing images in a multi-store configuration?
I'm going to start building this new image system.
i will also make sure the is a way of upgrading the images so that the system will find images in folders and move them to new folders based on dated added. it will then find each product or category suing the image and add a reference to the image_id
i will also make sure the is a way of upgrading the images so that the system will find images in folders and move them to new folders based on dated added. it will then find each product or category suing the image and add a reference to the image_id
OpenCart®
Project Owner & Developer.
Not smart, how would I know what folder is used with my product?Daniel wrote:i spotted on wordpress that images are saved in folders based on date.
so you would have one folder for year and another for date.
If it can be done with time-date then it could be done with a category-product tree.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Presumably if provision is being made to update or delete products and corresponding images in concert, then product-related subdirectories would be part of it. Of course, here we are just thinking over overviews of features, whose implementations will sort things out as they're laid out and fleshed out.
there are advantages and disadvantages to this system.i2Paq wrote:Not smart, how would I know what folder is used with my product?Daniel wrote:i spotted on wordpress that images are saved in folders based on date.
so you would have one folder for year and another for date.
If it can be done with time-date then it could be done with a category-product tree.
OpenCart®
Project Owner & Developer.
It should be done so that user can easily select which folder he uploads images.
It also should be possible upload images via FTP or add picture when you grate or edit product etc.
It also should be possible upload images via FTP or add picture when you grate or edit product etc.
Shipping methods: Matkahuolto, Posti, PostNord
Payment methods: Advance payment / Bank transfer, Checkout, Paytrail, Maksukaista
Modules: Prinetti, Matkahuolto's adress label, Random Products
vQmod: Checkout prices with tax, Product price input with tax
See my all modules
The ability to alternatively upload images via FTP is essential. There are many users maintaining the actual products and categories in Excel spreadsheets, uploaded via the Export/Import tool to the Opencart server. Therefore, there has to be an easy way to upload image files separately via FTP to a single, or at least easy to find, server folder. So I think this excludes the usage of timestamp folders like wordpress does!
If implementing support for sub-folders (e.g. for image categories) is too cumbersome, then your suggestion of using some sort of searchable image attributes or tags will be the only other reasonable option.
If implementing support for sub-folders (e.g. for image categories) is too cumbersome, then your suggestion of using some sort of searchable image attributes or tags will be the only other reasonable option.
Last edited by JNeuhoff on Mon Oct 21, 2013 5:52 pm, edited 1 time in total.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Who is online
Users browsing this forum: No registered users and 46 guests
