Progress Towards 1.5.0

SapporoGuy wrote:But the point is, how does the cart know the zip code?

I do what a US zip is ... 90210 ... however they are still limited to compared to Japan where you would have something like 90210-001 which would narrow it down to a street or neighborhood.

That's why I said you would limit it to the US, and have a zipcode text field under the shopping cart.

Xsecrets wrote:

SapporoGuy wrote: @ Sort of back to shipping estimatort
So, add on a module/extension/hack to pull shipping cost from the zip.
I don't see what the big deal is.

there already is a mod for this, but for some reason some people aren't happy unless their pet requirement is built into the core.

We're not happy because the mod would need to work with the latest version every time a new version is released.

alex1 wrote:We're not happy because the mod would need to work with the latest version every time a new version is released.

I wrote and maintain the Shipping Estimate module, and I update it to work with new OpenCart versions every time they are released, so that shouldn't really be a concern.

CUSTOM_UK wrote:Probably more than any other factor, the thing that really hacks people off with online shops is the checkout process.

I agree completely. The two main reasons I'll add something to a shopping cart but never finish checking out are 1) shipping costs; and 2) the length of time required to finish the transaction (in that order).

CUSTOM_UK wrote:Internet Explorer 6.0 usage, dependant on which figures you refer to, still accounts for around ten percent of browser usage. In the UK, official figures claim that 30 million people a day access the internet, so that is a potential of up to three MILLION folks still using IE6 in the UK alone.

While this is true, as others have mentioned a large part of that group is business, and one would think most of those businesses wouldn't be doing online shopping regularly. So the numbers are probably about right, but in reality the number of users affected would probably be far less than that.

SapporoGuy wrote:Of course, I want features to be added and they won't be and that's not fair either.

I think you completely misunderstood what I said in the last paragraph.

It's ok if some features get added and others don't - developers (D/Q) have to look at what's most beneficial for users/OC.

My comment about fairness was directed at your previous post which practically said "we can't do it in an airtight way, so let's not do it"

While everyone on this thread is on about the checkout process. Wouldn't it be better to put the coupon part on the cart page rather than on the two pages when entering shipping details, payment details in checkout etc. As a lot of people might not realize that you enter your coupon through the checkout process as most website have the enter coupon part at the cart page. This may lead to some loss sales as they might not think you can input their coupon. That's just my 2 cents.

mcfalcon wrote:While everyone on this thread is on about the checkout process. Wouldn't it be better to put the coupon part on the cart page rather than on the two pages when entering shipping details, payment details in checkout etc. As a lot of people might not realize that you enter your coupon through the checkout process as most website have the enter coupon part at the cart page. This may lead to some loss sales as they might not think you can input their coupon. That's just my 2 cents.

This was the case some versions back and then "you" all wanted it where it is now......

I haven't been around too long so I can't remember back then, but I think it would be way better having it in the cart page.

Going to give the option to add it to all checkout pages. Maybe make it a module

i2Paq wrote:

mcfalcon wrote:While everyone on this thread is on about the checkout process. Wouldn't it be better to put the coupon part on the cart page rather than on the two pages when entering shipping details, payment details in checkout etc. As a lot of people might not realize that you enter your coupon through the checkout process as most website have the enter coupon part at the cart page. This may lead to some loss sales as they might not think you can input their coupon. That's just my 2 cents.

This was the case some versions back and then "you" all wanted it where it is now......

No it wasn't. It was on the Checkout Confirmation page - where it made no sense at all.

The Payment Page is the most logical place to input discount coupons, voucher codes, etc. Shipping page is most logical place to enter free shipping codes, etc. So Q made a great decision in putting this field on these 2 pages.

However, there isn't any harm in also having this field on shopping cart page and shopping cart module. There could be a potential upside, but I don't quite see a downside.

sooskriszta wrote: No it wasn't. It was on the Checkout Confirmation page - where it made no sense at all.

actually you're not going far enough back. It used to be on the shopping page people complained it got moved to the confirmation page people complained it got moved to the payment page and people are complaining.

yea.. it was on confirmation page.. but that didn't allow FreeCheckout to work
It was moved to the cart page, but for people using ajax cart animation, most customers never see the cart
It was moved to the payment page, but then people with only 1 payment using the auto-choose tweak couldn't use it
so it was added to payment and confirmation to give more options.

Seems like the only way to make everyone happy is to make it configurable to be added to all checkout pages and maybe the cart sidebox

I changed my template and now that dang thing has given me a headache....

Where does Amazon have it?

sooskriszta wrote:

SapporoGuy wrote:Of course, I want features to be added and they won't be and that's not fair either.

I think you completely misunderstood what I said in the last paragraph.

It's ok if some features get added and others don't - developers (D/Q) have to look at what's most beneficial for users/OC.

My comment about fairness was directed at your previous post which practically said "we can't do it in an airtight way, so let's not do it"

I have no idea where you are coming from
I don't even remember saying it was "useless" either ...

Or, did I write in a way to make it sound "useless" and "pointles" ... but that doesn't fit my character either since I would come point out blank and say it.

Could you quote the areas better that gave you that impression?

I did say that it will have errors and you will need a fail safe.


As for the fairness part .....

Functionality as being part of the core:

My personal opinion would be since, there is an extension for XYZ than it can wait.

I'd rather have other issues attended to first that deal purely within the core itself rather than adding to the core.

Issues like, doubling checking security even more (never can enough of that koolaid), hard coded html, more modular design (including hooks and such ... although vmod sounds like it helps), cleaning up some of those text declarations (buttons should go to the top file), performance tuning (more HP is always a kicker), moving areas in modules (ie, the coupon thing just mentioned here) ... basically things that you would expect from a core frame work.

Some of those issues seem to be resolved in 1.5 and others may not.

Those are the things I want the most. I do not something that can be classified as "extension" being pumped into the core because people clammer for it or because it plays the role of "keeping up with the Jones".
However, if an "extension" needs something that benefit other extensions then of course those missing pieces of the frame work.

I'm aiming for the that fine line will help differentiate opencart from those who value "functionality" over frugal, wise, thought out awesomeness.

Also, since Daniel controls the base code, then I'd like to see him focus on things that we can't control.

I hope that clears up my ideas about "added functionality".

SapporoGuy wrote: Also, since Daniel controls the base code, then I'd like to see him focus on things that we can't control.

I'd like to see ample hooks and extensibility where we don't have to make any new code and it can all be community extensible. Then you all become the developers and we lay by the beach.

That will make opencart #1

and I am dead serious about that

Wasn't there a comment somewhere about Daniel wanting to make oc more modular?
I did mention that because that is what I mean by framework, not the MVC part that everybody tried to explain to me.
A framework on a framework.... LEGOS!!!

Yea Legos.. Lego has a factory made of legos that actually makes legos... the computers have taken over.. is all-hail-skynet.com taken?

The biggest problem with the traditional lego was that you could only do top and bottom.
Never could use the sides ... a real pain.

Screw the allspark, bionicles will rule!

Qphoria wrote: I'd like to see ample hooks and extensibility where we don't have to make any new code and it can all be community extensible. Then you all become the developers and we lay by the beach.

There's a cool project called VirtualQMod, maybe you should look into it

Yes, that would be Q's mod.
I have been following that thread since it started.

I still have to unzip that and try it out.