Progress Towards 1.5.0

I have a multi-vendor site,, pushed it for a while and had no takers so I just opened it up to industry specific free sites,, well I even had a hard time getting people to open a store for free... so out of experience,, its not worth it,, I am not so sure if its ok to post the link here and wouldn't do it unless I got a mod or admin approval,, so If they give me the go ahead I will post the link up if anyone is interested...

I am excited for 1.5.0 but I can wait until its finished,, Thanks for the great cart in the mean time.

My first post here, long time stalker, first time caller etc...

I've developed a few sites with Prestashop and Magento and have been actively seeking an e-commerce platform that takes into account the real-world needs of actual retailers (with restricted development budgets). Magento comes close but has been coded by inept hacks who blah blah blah...

I'm hoping v1.5 of Opencart provides proper back-end functionality with regards to modifying existing orders / placing new orders via phone sales etc (I understand this might be the case), but am also hoping for a flexible approach to multi-store functionality.

Unlike many of the requests for multi-store functionality, my desire is to have the ability to provide a custom shop-front for mobile device users. Qphoria's suggestion of store-id's is actually a very useful concept. In theory, adding this function shouldn't effect existing modules. It would however allow developers to provide a more tailored experience to mobile users.

Being able to serve different functionality (modules) and different content (images / xhtml / css) to mobile users would make Opencart hands-down the bees-knees! The 'store-id' would be a very simple way of providing developers the ability of achieving this.

Providing a mobile sub-domain (i.e m.mystore.com), would allow you to feed a different experience (and possibly a tailored catalogue) to these users. Currently this isn't possible.

Either way, I'm looking forward to the next release. You say it will be a game changer, you already changed the game a long time ago! Keep up the good work.

interwebber wrote:You say it will be a game changer, you already changed the game a long time ago!

Sign this guy up as your PR manager!

interwebber wrote:My first post here, long time stalker, first time caller etc...

I've developed a few sites with Prestashop and Magento and have been actively seeking an e-commerce platform that takes into account the real-world needs of actual retailers (with restricted development budgets). Magento comes close but has been coded by inept hacks who blah blah blah...

I'm hoping v1.5 of Opencart provides proper back-end functionality with regards to modifying existing orders / placing new orders via phone sales etc (I understand this might be the case), but am also hoping for a flexible approach to multi-store functionality.

Unlike many of the requests for multi-store functionality, my desire is to have the ability to provide a custom shop-front for mobile device users. Qphoria's suggestion of store-id's is actually a very useful concept. In theory, adding this function shouldn't effect existing modules. It would however allow developers to provide a more tailored experience to mobile users.

I guess you haven't really looked at the code then, as it would most definitely require every single module to be updated which is why no one has done it yet.

Being able to serve different functionality (modules) and different content (images / xhtml / css) to mobile users would make Opencart hands-down the bees-knees! The 'store-id' would be a very simple way of providing developers the ability of achieving this.

you can do this to a great extent already with a bit of hackery. No you can't have any modules on your mobile site that you don't have on your main site, but you can call module individually. I actually played around with creating a mobile store template that you could put on a subdomain, and it is quite doable.

Providing a mobile sub-domain (i.e m.mystore.com), would allow you to feed a different experience (and possibly a tailored catalogue) to these users. Currently this isn't possible.

Either way, I'm looking forward to the next release. You say it will be a game changer, you already changed the game a long time ago! Keep up the good work.

Multi-store was probably the deciding factor in my selecting Opencart - even though I didn't have an immediate need for it. I am not interested in multi-vendor; the main use for which would be people effectively acting as hosters. The fact though, that different sites all have to use the same payment gateway and account renders it pretty useless. I have continued to develop anyway on the basis that I will overcome this if/when the need arises.

The whole point would be to have different shops (in a larger case, franchise) with a mixture of global, shared and individual products. I can't think of a situation where I wouldn't want to account them separately.

If I wanted to run two radically different shops (eg books and lingerie), I would use two different shops on different domains. Multi-store would only be used for similar group of shops.

Opencart is 90% multi-store but not multi-vendor.

Let's separate the multi - vendor of multi - stores.
I like the owner can have different products and vendors.

But I want to have a common base of my customers. This is the most important to have one base for all stores!

Maybe general discounts and coupons for all my stores. But also be able to change the terms of each store (but with a total customer base).
In the beginning I want see full separate page for additional stores (different email, contacts, etc).

The most important thing I can not understand now, how googlebot and other bots are looking at the multi-store?

sys wrote: But I want to have a common base of my customers. This is the most important to have one base for all stores!

This is something that opencart DOES have currently

oneilldesign wrote:

interwebber wrote:You say it will be a game changer, you already changed the game a long time ago!

Sign this guy up as your PR manager!

Takes off his cheerleader kit and hangs his head in shame

Okay, so Opencart hasn't moved mountains yet, but compared to Prestashop / Zencart / etc, it's pretty damned good!

Xsecrets wrote: I guess you haven't really looked at the code then, as it would most definitely require every single module to be updated which is why no one has done it yet.

Okay, caught with pants firmly around ankles. Only looked into Opencart a few days ago and used the forum as my guide as opposed to the code (I'm a front-end hacker / back-end rapist, go figure...)

That said, surely adding 'id-store' won't adversely effect existing modules??? It should however allow future module updates the ability to utilise this flexibility, said the blind man...

Xsecrets wrote: You can do this to a great extent already with a bit of hackery. No you can't have any modules on your mobile site that you don't have on your main site, but you can call module individually. I actually played around with creating a mobile store template that you could put on a subdomain, and it is quite doable.

I'm afraid you just lost me. Any chance of some example forum posts that explain your asserted attempts ? I'm a fully-fledged copy-pasta expert, so any code examples would be awesome (I'm British so the word awesome is kinda inappropriate, my apology...)

Just to reiterate my previous cheerleader moves, the best part of Opencart is not the actual software (being an ignoramus to programming, I can only decipher shite coding as being shite. Good coding on the other hand...), BUT THE COMMUNITY. Not least because you ain't a bunch of frog eaters

mystifier wrote:Multi-store was probably the deciding factor in my selecting Opencart - even though I didn't have an immediate need for it. I am not interested in multi-vendor; the main use for which would be people effectively acting as hosters. The fact though, that different sites all have to use the same payment gateway and account renders it pretty useless. I have continued to develop anyway on the basis that I will overcome this if/when the need arises.

The whole point would be to have different shops (in a larger case, franchise) with a mixture of global, shared and individual products. I can't think of a situation where I wouldn't want to account them separately.

If I wanted to run two radically different shops (eg books and lingerie), I would use two different shops on different domains. Multi-store would only be used for similar group of shops.

Opencart is 90% multi-store but not multi-vendor.

I agree with what you are saying here except the multi-vendor script I have has seven different gateways so each store owner can pick which payment methods they want to accept along with the type of shipping they want..

My advise just run from multi-vendor its not worth the headaches.

interwebber wrote:

Xsecrets wrote: You can do this to a great extent already with a bit of hackery. No you can't have any modules on your mobile site that you don't have on your main site, but you can call module individually. I actually played around with creating a mobile store template that you could put on a subdomain, and it is quite doable.

I'm afraid you just lost me. Any chance of some example forum posts that explain your asserted attempts ? I'm a fully-fledged copy-pasta expert, so any code examples would be awesome (I'm British so the word awesome is kinda inappropriate, my apology...)

there are no forum posts. It's just something I was playing with locally for myself. I never actually finished it up. The only forum post I know of about mobile is the one for jquery mobile which looks fairly slick, but seems to have a few problems left.

Didn't bother to read 20+ pages.
However just reading the last page at the moment, I figure that people are asking for this and that to be added in.

I have been for the past few days hacking my cart to add in things.
Once again, love MVC-L even though I have no real clue as how to program php5. Old time here php3/4 ... ugh

Anyway, I was thinking that maybe 1.5 (call it 2.0 ) and go with a slightly different code design.

What I'm proposing is basically to go even more open as an architecture rather than the osc / zen code bloat.
The idea is differentiate opencart from other carts by turning it into a framework.
This would more than likely require having hooks/plugins versus the current patch/hack routine.
In a way ModX vs WordPress.
If opencart were a framework you could have downloads from the admin that would just install.

As Apple would say, less is more powerful.

SapporoGuy wrote:Didn't bother to read 20+ pages.
However just reading the last page at the moment, I figure that people are asking for this and that to be added in.

I have been for the past few days hacking my cart to add in things.
Once again, love MVC-L even though I have no real clue as how to program php5. Old time here php3/4 ... ugh

Anyway, I was thinking that maybe 1.5 (call it 2.0 ) and go with a slightly different code design.

What I'm proposing is basically to go even more open as an architecture rather than the osc / zen code bloat.
The idea is differentiate opencart from other carts by turning it into a framework.
This would more than likely require having hooks/plugins versus the current patch/hack routine.
In a way ModX vs WordPress.
If opencart were a framework you could have downloads from the admin that would just install.

As Apple would say, less is more powerful.

Before Daniel sees this I will correct you nicely opencart is a framework, or more precisely it is built upon a MVC-L framework that Daniel created, and it's a very nice easy to understand framework.

What you are asking for is hooks/overrides/whatever else it is you want to call them. That may happen at some point in the future, but it won't be in 1.5.x. If it happens it probably will be in 2.0, but as you can see people are already clamoring for 1.5.x and something like that is many many months worth of work. If you look over the forums you will see that pretty much all of the developers want what you are asking for as well, but like I said it's a lot of work, and there are many many ways to do it, so the devs have to figure out how the best way would be for opencart.

Xsecrets wrote:If it happens it probably will be in 2.0, but as you can see people are already clamoring for 1.5.x and something like that is many many months worth of work. If you look over the forums you will see that pretty much all of the developers want what you are asking for as well, but like I said it's a lot of work, and there are many many ways to do it, so the devs have to figure out how the best way would be for opencart.

Yeah, 1.5 needs to be rock-solid before anything major is changed.

when you mention hooks you mean the observer pattern.

I don't see any advantage in using them. they only might help some mod developers to over ride things but they increase the complexity of the code and the developers have to learn where the hooks are, what functionality they have, what they override etc..

Its not really KISS.

Qphoria wrote:

sys wrote: But I want to have a common base of my customers. This is the most important to have one base for all stores!

This is something that opencart DOES have currently

You pulled it out of total context.
I only said that it is important for multi-store, but not quite functional as it is now.
What you need at least a little flexibility for additional stores.
Now you can not even assign each store their own email and other important attributes

P.S.
I will not be against if an additional extension for the store will be fee

sys wrote:

Qphoria wrote:

sys wrote: But I want to have a common base of my customers. This is the most important to have one base for all stores!

This is something that opencart DOES have currently

You pulled it out of total context.
I only said that it is important for multi-store, but not quite functional as it is now.
What you need at least a little flexibility for additional stores.
Now you can not even assign each store their own email and other important attributes

P.S.
I will not be against if an additional extension for the store will be fee

sorry man i was a bit stressed with trying to get 1.5.0 out.

ANyway adding multiple emails for the different stores is quite easy, i left it out because i was just trying to get the functionaliy of the mulit store working and missed this part out.

SapporoGuy wrote: What I'm proposing is basically to go even more open as an architecture rather than the osc / zen code bloat.
The idea is differentiate opencart from other carts by turning it into a framework.
This would more than likely require having hooks/plugins versus the current patch/hack routine.
In a way ModX vs WordPress.
If opencart were a framework you could have downloads from the admin that would just install.

Daniel wrote:when you mention hooks you mean the observer pattern.

I don't see any advantage in using them. they only might help some mod developers to over ride things but they increase the complexity of the code and the developers have to learn where the hooks are, what functionality they have, what they override etc..

Its not really KISS.

I agree with Sapporo and disagree with Daniel completely on this one.

I think a major issue with OpenCart is that it is too static. The extension system is the only dynamic piece in the entire cart. People have to request every little tiny feature...
- a new account field
- An extra product field
- a show/hide toggle for categories
- a new menu item in the admin menu
etc


These are all things that REQUIRE core edits to a minimum of 3 files. There is no way to make an external mod for them at this time. In the end it just leaves us developers with busy work that could be handled by the community once and as long as the API doesn't change, could work the same for all versions without worrying about upgrades.

I think with a more dynamic structure where hooks and overrides can actually make changes within the core without ever touching the core files is the future. Then we spend less time on the mundane and more on major features.

I have been looking into retrofitting a plugin/observer class outside of the core because I and some 99% of others agree that it would make opencart even better.

Events that trigger other plugged-in events like:
- New Account created
- New Order Placed
- Item added to cart
- Item removed from cart
- customer login
- customer logoff

Basically any event that changes something in the session would call a "DoEvent()" function that external plugins could be triggered on.

For example, if you wanted to add a free item to the cart automatically after a customer adds his 3rd item.
Currently you'd have to edit the core system/library/cart.php file and add the code
If there was a hook system, it would be triggered when each item is added to the cart. The external code could then check the session and add the item when the cart count = 3. That is a simple example but it would work.

So no promises or dates on when but it is on the radar for some of us.

Qphoria wrote:

Daniel wrote:they increase the complexity of the code and the developers have to learn where the hooks are, what functionality they have, what they override etc

I agree with Sapporo and disagree with Daniel completely on this one.

Me too. I'm no developer but surely the end product is more important than the complexity of the code (to a point, at least). With comments, documentation and other resources available to developers then it would be up to them to learn the system. The software shouldn't be held back for the sake of less code.

oneilldesign wrote:

Qphoria wrote:

Daniel wrote:they increase the complexity of the code and the developers have to learn where the hooks are, what functionality they have, what they override etc

I agree with Sapporo and disagree with Daniel completely on this one.

Me too. I'm no developer but surely the end product is more important than the complexity of the code (to a point, at least). With comments, documentation and other resources available to developers then it would be up to them to learn the system. The software shouldn't be held back for the sake of less code.

And the code is another thing on my hitlist. The tedious language declarations have already been resolved in the engine. The next step is to clean it up in the controllers. That will be one less thing to worry about. Then the errors, settings, and validation is next. A simple array with 1 loop instead of the dozens of repeats. And finally I'd like to clean up the url generation mess. There is too much repetitive code at the moment. We could probably cut it back to a third of the code if we applied some minor changes to process. And finally that damn url class!!!

Qphoria wrote:And finally that damn url class!!!

I thought you loved that!!!