OpenCart 1.6.0 Roadmap

I have to say Ive used various cart systems over the years and I for one would say -

1. A very good plugin system, that doesnt change core files, or if it does would auto update them when the cart is updated, as when you run many addons you can get lost to where you are and what works with what, and what code needs to be changed where....

2. Expanded attributes, as we sell many similar items but each of the items have their own sku, thus we don't need to add 4 very simular versions of the same item, just put on on with separate skus/prices/pictures so you can easily see the difference and choose the one you want.

3. A system to send order information to various drop shippers, (email, and/or soap api integration), once the order has been placed . Many shops that I run for others have items they ship and many items they drop ship, but want easy low hassle integration method where the cart system strips the order into individual parts and sends the data to the separate drop-shippers and their own warehouse with out user interaction.

Thats a few just off the top of my head...

Out2lunch wrote: 3. A system to send order information to various drop shippers, (email, and/or soap api integration), once the order has been placed . Many shops that I run for others have items they ship and many items they drop ship, but want easy low hassle integration method where the cart system strips the order into individual parts and sends the data to the separate drop-shippers and their own warehouse with out user interaction.

email, and/or soap api integration well now there's the rub isn't it. Every dropshipper has thier own format be it email or soap api, so which one/ones do you support? This is the real problem with a dropshipper system there is no standard way to implement it for everyone. Not to mention that since you want it broken out per product now you have to have some sort of a suppliers system in place that you can assign to the products.

Wow.. Multi Vendor.. Long time waiting for this option. Thanks for adding in 1.6.0...

Xsecrets wrote:

Out2lunch wrote: 3. A system to send order information to various drop shippers, (email, and/or soap api integration), once the order has been placed . Many shops that I run for others have items they ship and many items they drop ship, but want easy low hassle integration method where the cart system strips the order into individual parts and sends the data to the separate drop-shippers and their own warehouse with out user interaction.

email, and/or soap api integration well now there's the rub isn't it. Every dropshipper has thier own format be it email or soap api, so which one/ones do you support? This is the real problem with a dropshipper system there is no standard way to implement it for everyone. Not to mention that since you want it broken out per product now you have to have some sort of a suppliers system in place that you can assign to the products.

I don't see this as too difficult - (im not a coder, this is how I see it working, but could be well off the mark).

1. To strip the orders, needs an extra field for each product, new field - dropshipper (name of drop shipper).

2. Set up a new section called dropshipper, (a bit like manufacturer), where you add their details. Eg boolean field for email or api integration. If email , then forward order id, customer info and product for that dropshipper then info in a packing slip or email and post.

If api integration, then a page with the opencart db fields for the product and customer info, and a blank box next to each where you put in their api variable that matches your db field. so that page translates your field to theirs, then perhaps a box for number order that they want to accept your order as. eg 1. first name, 2. last name 3. etc etc etc...

Then login / pass & api web address to post the info to.



Perhaps thats too simple as I say im not a coder, thus could be way off the mark.



I see it working that when an order is paid for, the status is changed to paid or whatever, then when the system creates the emails etc to post to customer it strips the order down, mails/api each of the parts of the order as per dropship info and thus the job is more or less done, as the customer gets a status upgrade with sent to x,y,z warehouse for processing.

As a bolt on, if tracking information can be pulled back from dropshipper/warehouse, then a cron job to pulse the various systems to see if tracking information is available to be pulled into our db and then emailed to the customer.

Also additional bolt on would be stock level grab from dropshipper etc to see if stock is available and how much is available, and thus update your own stocklevel.

Add the User to the order history, so it is possible to see who made the changes.
Add a status and a history to each order_product. This way, partially finished orders can be communicated to the customer. Also this makes it possible to cancel single items of an order which is much more transparent than just deleting it. For this order_product also a history is required.

Dear Daniel ,
You are one of my feverate person which I liked, I have a request about 1.6.0, roadmap, actually I have more than 23 vendors and most of located different cities, so I was facing to calculate shipping. e.g
Khi to khi = $100
Khi to Lhr = $160
Lhr to IBD = $110
And so on, I think you understand my request…

Would be good to see some search improvements.

justinv wrote:Would be good to see some search improvements.

+1

Please add
Percentage discounts for customer groups.
Product filter by category, price, size, color, etc.

News, blog & photo gallery modules.

Allow newsletter signup without first having to create an account.

Daniel wrote:

Xsecrets wrote:plugins should be at the minimum bundled up into one file with an admin control where you can browse that file and install it track what plugins are installed etc. If it can be made to link back to the extension store so the users don't have to download the extension first even better. Look at pretty much any CMS on the market none of them require you to unzip the extension and upload all the files separately. The end user many times has no idea what ftp is. If you wanted to take it farther looking into hooks and class overrides would be good, but with the current situation most of this can be gotten around with vqmod, but of course that is not in the core distribution at this point either. Basically it needs to be made much easier for a non technical user to install extensions.

yes i was thinking about adding vqmod to the core. only well tested plugins woulpld be available to purchase directory via the admin.

Just to note, vQmod and plugins are not really related. While it would be nice to have the vQmod as part of the core to remove the install step, extensions and package installers are still needed and unrelated. I think SMF nailed the plugin system as they have the option to install a zip or browse a live repository server directly from the admin area. From here the mods can be directly installed or updated, and a "test" is done first to verify the changes are valid before installing. Then uninstalls go and remove all the files.

Qphoria wrote:

Daniel wrote:

Xsecrets wrote:plugins should be at the minimum bundled up into one file with an admin control where you can browse that file and install it track what plugins are installed etc. If it can be made to link back to the extension store so the users don't have to download the extension first even better. Look at pretty much any CMS on the market none of them require you to unzip the extension and upload all the files separately. The end user many times has no idea what ftp is. If you wanted to take it farther looking into hooks and class overrides would be good, but with the current situation most of this can be gotten around with vqmod, but of course that is not in the core distribution at this point either. Basically it needs to be made much easier for a non technical user to install extensions.

yes i was thinking about adding vqmod to the core. only well tested plugins woulpld be available to purchase directory via the admin.

Just to note, vQmod and plugins are not really related. While it would be nice to have the vQmod as part of the core to remove the install step, extensions and package installers are still needed and unrelated. I think SMF nailed the plugin system as they have the option to install a zip or browse a live repository server directly from the admin area. From here the mods can be directly installed or updated, and a "test" is done first to verify the changes are valid before installing. Then uninstalls go and remove all the files.

true, but vqmod will allow you to be able to do useful stuff without having to go back and completely implement a hook/override system. At the current point without vqmod a nice system for installing mods would be almost completely useless because any mod of real substance has to change core files.

I would love to see AJAX search suggest.
A better way to add the related products it's a real pain right now. Same for product options..

One feature that would really help users OpenCart would be the implementation of custom fields in the registration form.

-- Missing a field in the back office that allows choosing a minimum value to validate the purchase.

tks !

Xsecrets wrote: true, but vqmod will allow you to be able to do useful stuff without having to go back and completely implement a hook/override system. At the current point without vqmod a nice system for installing mods would be almost completely useless because any mod of real substance has to change core files.

Yes, but a vqmod script would be part of the "package". Like my offline CC mod would come as a zip file with admin and catalog folders... and a vqmod/xml/offline_cc.xml script inside the zip. But the package installer would be needed regardless of that mod using vqmod or not.

Qphoria wrote:

Xsecrets wrote: true, but vqmod will allow you to be able to do useful stuff without having to go back and completely implement a hook/override system. At the current point without vqmod a nice system for installing mods would be almost completely useless because any mod of real substance has to change core files.

Yes, but a vqmod script would be part of the "package". Like my offline CC mod would come as a zip file with admin and catalog folders... and a vqmod/xml/offline_cc.xml script inside the zip. But the package installer would be needed regardless of that mod using vqmod or not.

absolutely. There are two different things being discussed. Vqmod being added to the core. once you have that it greatly helps in creating a package installer because it allows for more useful mods, plus it gives you an easy place to store some of the information by just adding a few parameters to the xml format.

- How about support for CDN? I think its getting more an more popular to use CDN for our stores.
- Also I feel as a store owner myself, that some quicker way to process orders can be thought of in admin. For e.g. updating multiple orders are one time. Right now we have to open each order to process it.

- Option for Externally hosted images (per-product)

Qphoria wrote:- Option for Externally hosted images (per-product)

How exactly would you go about this though? not only would you have to allow for a url to be entered then you would have to have some way to keep them from being run through the resize and caching systems, and of course once you do that then you would have to allow for 3-4 different sizes to be entered for each image.