Hi,
I have been working on a file upload addition to OpenCart. It is coming along nicely, but I still have some more work to do before I can make it available. This feature is intended to make it possible to order items with custom photos printed on them. (For example, coffee cups, baseball caps, T-shirts, etc.)
I invite you to try out the feature and offer your feedback for improvements. You can find a demonstration site at:
The site is just a simple, out-of-the-box OpenCart site with the file upload additions and one product set up with an upload option. Choose the "Canvas Photo" item and look for the "Upload" button. Please kick the tires and tell me what you absolutely hate about it. If you want to see the administrative side (where the uploaded file can be downloaded by the administrator), send me a private message on this board and I will create an administrator account for you.
I have a little more work to do on the extension and since v0.8 is coming so soon, I will hold off making it available until I've integrated it with the new version of OpenCart.
I've made some design choices that warrant some discussion with the experienced OpenCart developers and I hope I am not out of line to post technical discussion in followup messages to this topic.
cheers,
Randall Krebs
I have been working on a file upload addition to OpenCart. It is coming along nicely, but I still have some more work to do before I can make it available. This feature is intended to make it possible to order items with custom photos printed on them. (For example, coffee cups, baseball caps, T-shirts, etc.)
I invite you to try out the feature and offer your feedback for improvements. You can find a demonstration site at:
The site is just a simple, out-of-the-box OpenCart site with the file upload additions and one product set up with an upload option. Choose the "Canvas Photo" item and look for the "Upload" button. Please kick the tires and tell me what you absolutely hate about it. If you want to see the administrative side (where the uploaded file can be downloaded by the administrator), send me a private message on this board and I will create an administrator account for you.
I have a little more work to do on the extension and since v0.8 is coming so soon, I will hold off making it available until I've integrated it with the new version of OpenCart.
I've made some design choices that warrant some discussion with the experienced OpenCart developers and I hope I am not out of line to post technical discussion in followup messages to this topic.
cheers,
Randall Krebs
One of the choices I've made to implement file upload is the use of Perl. From what I've been able to glean from the collective wisdom of the web, file uploads in PHP require a special PHP extension that provides the necessary hook to implement a progress bar. I thought the addition of such an extension may be beyond the skills of the typical OpenCart store owner. Another common problem with PHP file upload is the 2 megabyte file size limit. Yes, it can be worked around depending on your hosting service, but Perl doesn't have such a low default limit on the upload size. Since I am interested in uploading image files from 12 megapixel cameras, this is an important issue to me.
The result is somewhat Rube Goldberg-esque. Javascript in the user's browser posts the file upload in a dynamic iframe to the Perl script and then periodically hits an Ajax PHP script to retrieve the upload progress. The Perl script updates the progress and the PHP script retrieves it, so I decided to keep the transient progress information in the opencart database itself. I don't know if OpenCart is 100% web farm capable, but use of the database should avoid any future problems with updating the progress bar.
I haven't written the installer/uninstaller for the file upload extension yet. When I do, I will attempt to put the Perl CGI script in the cgi-bin directory and set values appropriately so that the Perl script can communicate with the OpenCart database and place uploaded files in the correct directory so that the rest of the extension code (in PHP) can find them.
Comments?
randall.
The result is somewhat Rube Goldberg-esque. Javascript in the user's browser posts the file upload in a dynamic iframe to the Perl script and then periodically hits an Ajax PHP script to retrieve the upload progress. The Perl script updates the progress and the PHP script retrieves it, so I decided to keep the transient progress information in the opencart database itself. I don't know if OpenCart is 100% web farm capable, but use of the database should avoid any future problems with updating the progress bar.
I haven't written the installer/uninstaller for the file upload extension yet. When I do, I will attempt to put the Perl CGI script in the cgi-bin directory and set values appropriately so that the Perl script can communicate with the OpenCart database and place uploaded files in the correct directory so that the rest of the extension code (in PHP) can find them.
Comments?
randall.
One of the difficulties I ran into while writing the file upload extension to OpenCart involves the way that product options and values are implemented. I wanted the uploaded file to behave similar to a standard product option (like Size, Colour, etc.), but I wanted the value of the option to be derived from the name of the file that was uploaded.
The benefit is that two identical items in the shopping cart that vary only by the uploaded image file will not be merged by quantity.
However, as implemented in v0.7.8, the name of an option can only come from the option table and the name of the option value can only come from the option_value table. This presented a challenge.
I opted to modify the core code of OpenCart to make ProductOption a first-class extensible object in OpenCart. In fact, all of the UI to upload a file, update a progress bar, and display thumbnails of the image are implemented as the "upload" extension to the ProductOption. This makes it possible for the bulk of the file upload feature to be cleanly added as any other extension in OpenCart. The difference is that the ProductOptionUpload class which implements all the UI for the the file upload is an extension to a new class of extensible object (somewhat similar to the Module, Calculate, Shipping, and Payment classes).
But there is another complication to using the product options for this. The standard options have three different storage formats in OpenCart. When stored in the session, the product_to_option_id is used. When stored in the cart, a product option is represented by an associative array using the option_id and option_value_id. When stored in the order_option table, the names from the option table and the option_value table are used. I understand the justification for the format change when the order is created -- you don't want to lose the human-readable option values in an order just because later changes are made to the option and option_value tables.
In any case, this adds a bit of complexity to the subclasses of ProductOption -- they must be responsible for generating those three storage values along with generating different UI to implement the file upload and to display thumbnail images in the shopping cart and the order confirmation page. Also, if the upload extension is removed, the orders with such options will then display the raw data of the storage format (a serialized array). This isn't ideal, but at least the information remains and an administrator could locate the associated uploaded file manually if necessary.
By the way, the value field in the order_option table was a varchar(32). This just didn't provide enough storage space for the serialized associative array. I've expanded it to varchar(255).
This last "feature" is pretty hokey. I needed to distinguish whether the stored value for an option is a standard option value or a ProductOption extension value. I prefixed a caret ('^') to the serialized associative array so that I know to create a ProductOption extension class instance using a ProductOption factory method when rendering the UI for the shopping cart, order confirmation, and account invoice pages. The best thing I can say about it is that it works. I'm open to better suggestions for this.
Comments?
randall.
The benefit is that two identical items in the shopping cart that vary only by the uploaded image file will not be merged by quantity.
However, as implemented in v0.7.8, the name of an option can only come from the option table and the name of the option value can only come from the option_value table. This presented a challenge.
I opted to modify the core code of OpenCart to make ProductOption a first-class extensible object in OpenCart. In fact, all of the UI to upload a file, update a progress bar, and display thumbnails of the image are implemented as the "upload" extension to the ProductOption. This makes it possible for the bulk of the file upload feature to be cleanly added as any other extension in OpenCart. The difference is that the ProductOptionUpload class which implements all the UI for the the file upload is an extension to a new class of extensible object (somewhat similar to the Module, Calculate, Shipping, and Payment classes).
But there is another complication to using the product options for this. The standard options have three different storage formats in OpenCart. When stored in the session, the product_to_option_id is used. When stored in the cart, a product option is represented by an associative array using the option_id and option_value_id. When stored in the order_option table, the names from the option table and the option_value table are used. I understand the justification for the format change when the order is created -- you don't want to lose the human-readable option values in an order just because later changes are made to the option and option_value tables.
In any case, this adds a bit of complexity to the subclasses of ProductOption -- they must be responsible for generating those three storage values along with generating different UI to implement the file upload and to display thumbnail images in the shopping cart and the order confirmation page. Also, if the upload extension is removed, the orders with such options will then display the raw data of the storage format (a serialized array). This isn't ideal, but at least the information remains and an administrator could locate the associated uploaded file manually if necessary.
By the way, the value field in the order_option table was a varchar(32). This just didn't provide enough storage space for the serialized associative array. I've expanded it to varchar(255).
This last "feature" is pretty hokey. I needed to distinguish whether the stored value for an option is a standard option value or a ProductOption extension value. I prefixed a caret ('^') to the serialized associative array so that I know to create a ProductOption extension class instance using a ProductOption factory method when rendering the UI for the shopping cart, order confirmation, and account invoice pages. The best thing I can say about it is that it works. I'm open to better suggestions for this.
Comments?
randall.
Nice work, It works exactly as I would expect it to.
Too bad this can't be achieved without modifying the core files
.. However, this feature would be a good addition to an upcoming release (0.9??) wink 
Good Job Randall,
-JO
Too bad this can't be achieved without modifying the core files


Good Job Randall,
-JO
If you make it idiot proof, they will just build a better idiot.
Thank you, JO. I can't think of a nicer compliment!JohnnyO wrote: It works exactly as I would expect it to. [...]
randall.
My first upload, 3.5 MB jpg worked fine. I found it a bit unsettling to see your photo in the cart, but you solved my problem by having the mouse-over link to my photo.
My second upload was a 94MB tif. Maybe I wasn't patient enough, but nothing seemed to be happening. I eventually canceled the upload.
Nice work!
My second upload was a 94MB tif. Maybe I wasn't patient enough, but nothing seemed to be happening. I eventually canceled the upload.
Nice work!
Good point. Thanks for the user feedback. When I put up the actual site, I'll make sure that the primary product image is just a diagram.perlgerl wrote: [...] I found it a bit unsettling to see your photo in the cart, but you solved my problem by having the mouse-over link to my photo.
I set the upload limit size to 12MB. The error handling needs work [sigh].perlgerl wrote: [...] My second upload was a 94MB tif. Maybe I wasn't patient enough, but nothing seemed to be happening. I eventually canceled the upload. [...]
I'm currently working on the extension installer. Probably another weekend of work to go on the extension. Middle of October, maybe?
Randall.
I've had an inquiry about availability, so I'm posting an update in case anyone else is curious.
My target date for release of the file upload extension for OpenCart v0.7.9 is October 13th, 2008.
I still need to add or enhance the following features:
Over the coming weeks, I'll ask/lobby/beg the developers working on the beta to consider incorporating the core file mods in the 1.0 beta or develop equivalent functionality. I think that extending product options could open some very exciting avenues for subsequent contributions.
randall.
My target date for release of the file upload extension for OpenCart v0.7.9 is October 13th, 2008.
I still need to add or enhance the following features:
- error handling
- file extension restrictions (jpg, jpeg, gif, bmp, tiff)
- input validation
Over the coming weeks, I'll ask/lobby/beg the developers working on the beta to consider incorporating the core file mods in the 1.0 beta or develop equivalent functionality. I think that extending product options could open some very exciting avenues for subsequent contributions.
randall.
When all is done and working, it would be best for you to create an Enhancement request on the bug tracker system. Ideas and bugs posted there get noticed much more easily as well as logging the steps being taken to make the changes. Makes developing a lot easier when we have all requests in one location.
But wait until you've released it as a contrib and it tests out ok, in the mean time Daniel still has quite a bit of work to finish up on 1.x
Cheers
But wait until you've released it as a contrib and it tests out ok, in the mean time Daniel still has quite a bit of work to finish up on 1.x
Cheers

I am still working on this contribution. I've missed the self-imposed target date for making it available, but I hope to make it available within a couple of days.randomfactor wrote: [...]
My target date for release of the file upload extension for OpenCart v0.7.9 is October 13th, 2008.
[...]
There will be some rough edges.
randall.
A preliminary version of this extension is complete and available at http://www.opencart.com/contribution/in ... tion_id/73randomfactor wrote: [...]
I am still working on this contribution. I've missed the self-imposed target date for making it available, but I hope to make it available within a couple of days.
[...]
Who is online
Users browsing this forum: No registered users and 2 guests