Community Forums

by **Qphoria** » Wed Jul 27, 2011 8:07 pm

And upgrade script is only needed for database changes. 1.5.1.1 does come with an upgrade script but if you are coming from 1.5.1 to 1.5.1.1 there was only 1 file changed.

by **ehandelsfabriken** » Wed Jul 27, 2011 8:30 pm

Qphoria wrote:And upgrade script is only needed for database changes. 1.5.1.1 does come with an upgrade script but if you are coming from 1.5.1 to 1.5.1.1 there was only 1 file changed.

Which file?

by **Qphoria** » Wed Jul 27, 2011 8:44 pm

I don't know.. but someone said they used windiff to compare 1.5.1 to 1.5.1.1 and only one file was diff
IIRC catalog/view/theme/default/checkout/checkout.tpl

by **SuperJuice** » Thu Jul 28, 2011 12:57 pm

Can someone explain how I am to determine what unit a length type is by it's length_class_id? without querying the database? when accessing the item arrays returned back using:

Code: Select all: $this->cart->getProducts()

I can't trust the length_class_id to be the same as what was shipped because at any stage a user can potentially modify / remove / add length classes, so the length_class_id is useless to me (and anyone else I would suggest) unless I can reference it by unit.

Can someone tell me how to get the length_class_id from a unit such as cm or mm? or to determine if an item in the cart is in mm or cm (based on the fact the length_class_id for that unit can change at any time and can't be trusted) ?

I gather it's available somehow, but I haven't found an example in the 1.5.1 release that uses it.

by **Xsecrets** » Thu Jul 28, 2011 1:16 pm

SuperJuice wrote:Can someone explain how I am to determine what unit a length type is by it's length_class_id? without querying the database? when accessing the item arrays returned back using:

Code: Select all
$this->cart->getProducts()

I can't trust the length_class_id to be the same as what was shipped because at any stage a user can potentially modify / remove / add length classes, so the length_class_id is useless to me (and anyone else I would suggest) unless I can reference it by unit.

Can someone tell me how to get the length_class_id from a unit such as cm or mm? or to determine if an item in the cart is in mm or cm (based on the fact the length_class_id for that unit can change at any time and can't be trusted) ?

I gather it's available somehow, but I haven't found an example in the 1.5.1 release that uses it.

I think you have a fairly firm grasp on it. you'll need to query the db. I suppose you could say that none of your db information can be trusted because it can all be changed. In my experience you don't change your length classes much. If you are actually going to use them I would suggest you just don't change them.

by **SuperJuice** » Thu Jul 28, 2011 1:21 pm

Xsecrets wrote:
SuperJuice wrote:Can someone explain how I am to determine what unit a length type is by it's length_class_id? without querying the database? when accessing the item arrays returned back using:

Code: Select all
$this->cart->getProducts()

I can't trust the length_class_id to be the same as what was shipped because at any stage a user can potentially modify / remove / add length classes, so the length_class_id is useless to me (and anyone else I would suggest) unless I can reference it by unit.

Can someone tell me how to get the length_class_id from a unit such as cm or mm? or to determine if an item in the cart is in mm or cm (based on the fact the length_class_id for that unit can change at any time and can't be trusted) ?

I gather it's available somehow, but I haven't found an example in the 1.5.1 release that uses it.

I think you have a fairly firm grasp on it. you'll need to query the db. I suppose you could say that none of your db information can be trusted because it can all be changed. In my experience you don't change your length classes much. If you are actually going to use them I would suggest you just don't change them.

I am writing a modification that hundreds of people use, to suggest that I say "just don't change your length class settings because it will break the mod" is ridiculous, people modify settings all the time.

I don't see the reason that the unit title was removed from the array when it was available in 1.5.0.5? Now you want a shipping module to query the database directly to request something that should be exposed as part of the items array? That is subverting the entire plugin/module API to get a piece of basic information about a product, and I am only the first to complain of many I am sure.. switching to referencing by ID gained nothing.

by **lvcoded** » Thu Jul 28, 2011 2:07 pm

Guys,

Is it finally possible to upgrade from 1.5.0.5 to 1.5.1.x ?
We have spent all day trying to upgrade using 1.5.1.1 upgrade script on our 1.5.0.5 installation only to find that all modules have disappeared and will only work if reinstalled, which is kinda pain in the ass, as we might as well have simply installed a fresh 1.5.1.1 installation.

Also saw somewhere that upgrading from 1.5.0.5 to 1.5.1 was not possible. I think if its not possible to upgrade, its better not to release a new version at that time as all it does is piss off your customers.. If you cant upgrade your live store from one version to another, then that new version is only useful to new customers so no one at the point of release.. I completely understand that upgrade script can not be released on the same day as a new major version of OpenCart like it was from 1.4 to 1.5, but to say upgrading from 1.5.0.5 to 1.5.1 is not possible is just ridiculous.

Hope that instead of slagging me off, you will think about it and improve..

Thank you,
Igo

by **SuperJuice** » Thu Jul 28, 2011 2:11 pm

If it didn't break during upgrades:
* No OpenCart support companies would make money because upgrading would be too easy
* For-money developers wouldn't make money re-selling the same mods when version updates broke them

I have ended up adding database queries to a shipping module just to make it work with 1.5.1.1.. as I know from experience that any suggestion that the developers have made an error of judgement is treated with contempt.

Thanks for your help and support.

by **Xsecrets** » Thu Jul 28, 2011 3:11 pm

SuperJuice wrote:switching to referencing by ID gained nothing.

obviously you know how db queries work, so you know well what is gained. You eliminate an extra subquery to pull the actual name. Regardless if you go in the backend and change your length classes it's going to change the results no mater if you query it in the main query or a separate query. I don't really see the problem. Even if you have millions of people using it how often do you need to change your length classes. That is something that should be set one time on store setup and never touched again.

by **Wabun** » Thu Jul 28, 2011 3:32 pm

Daniel,

I noticed you have twice this field in products.php, row 23, 24 version 1.5.1.1

'model' => $query->row['model'],
'model' => $query->row['model'],

Another things is that my field cost for the product is gone missing, why?

One more thing, I have filecompared all changes from v1.5.1.0 to v1.5.1.1 and so far only 7 files changed.

Cheers,

by **SuperJuice** » Thu Jul 28, 2011 3:32 pm

Xsecrets wrote:
SuperJuice wrote:switching to referencing by ID gained nothing.

obviously you know how db queries work, so you know well what is gained. You eliminate an extra subquery to pull the actual name. Regardless if you go in the backend and change your length classes it's going to change the results no mater if you query it in the main query or a separate query. I don't really see the problem. Even if you have millions of people using it how often do you need to change your length classes. That is something that should be set one time on store setup and never touched again.

The problem is people _can_ change it, so you need to account for that. As a programmer i'd expect you to have a greater interest in a solution, and less of a "people shouldn't do that, it's the user's fault!" attitude.

You eliminate an extra subquery at your end.. so that module developers have to write it into their code at their end? what a great saving. It's not even a subquery, it's a join to a table with 3 fields, and inserting a field in an array. The time saving will be in the sub ms.

So now that I have had to query the DB from the module, I now depend on the database structure not changing.. and we all know database changes never happen in OpenCart... right?

Obviously you know the point of creating standardised application API's so module developers are abstracted from the 'heavy lifting'.. and you surely understand the benefits of retaining API compatibility across versions? So why doesn't OpenCart take any interest in doing this?

by **Xsecrets** » Thu Jul 28, 2011 4:00 pm

SuperJuice wrote:
The problem is people _can_ change it, so you need to account for that. As a programmer i'd expect you to have a greater interest in a solution, and less of a "people shouldn't do that, it's the user's fault!" attitude.

You eliminate an extra subquery at your end.. so that module developers have to write it into their code at their end? what a great saving. It's not even a subquery, it's a join to a table with 3 fields, and inserting a field in an array. The time saving will be in the sub ms.

well I don't actually write opencart you'll have to talk to Daniel about that. Sure it doesn't save much, but it doesn't really matter either. So you have the value in the array that doesn't change the fact that a user can change it and then the next time you pull that query it will be different, so I don't see what you are on about. Weather it's pulled in the original array or later on doesn't change the fact that users can change it, as a matter of fact it doesn't change anything other than in the few ms it will take you to query the db again a user could change it then which is highly unlikely.

by **dony_b** » Thu Jul 28, 2011 4:08 pm

Will there be any new release soon like 1.5.2 or anything like that as I see some changes in Google code ?

by **Qphoria** » Thu Jul 28, 2011 7:35 pm

lvcoded wrote:Guys,

Is it finally possible to upgrade from 1.5.0.5 to 1.5.1.x ?
We have spent all day trying to upgrade using 1.5.1.1 upgrade script on our 1.5.0.5 installation only to find that all modules have disappeared and will only work if reinstalled, which is kinda pain in the ass, as we might as well have simply installed a fresh 1.5.1.1 installation.

Yes that is the process... hardly the same as reinstalling.. you just have to reinstall the modules.. not the shipping, payments, orders, customers, products, etc. The upgrade script comes with 1.5.1.1

by **amitgarg** » Fri Jul 29, 2011 6:00 am

This is really cool, i love open cart but still there are some features that need to be added.

by **amertad** » Sat Jul 30, 2011 2:49 pm

hi .

auto complate in products (option+attributes) ..not works whit UTF8 chars...

thanks

by **Daniel** » Sat Jul 30, 2011 2:57 pm

amertad wrote:hi .

auto complate in products (option+attributes) ..not works whit UTF8 chars...

thanks

which utf-8 characters?

i just tested it with ä and it works fine. are you typing the name of the global attributes?

by **Daniel** » Sun Jul 31, 2011 7:04 am

lvcoded wrote:Guys,

Is it finally possible to upgrade from 1.5.0.5 to 1.5.1.x ?
We have spent all day trying to upgrade using 1.5.1.1 upgrade script on our 1.5.0.5 installation only to find that all modules have disappeared and will only work if reinstalled, which is kinda pain in the ass, as we might as well have simply installed a fresh 1.5.1.1 installation.

Also saw somewhere that upgrading from 1.5.0.5 to 1.5.1 was not possible. I think if its not possible to upgrade, its better not to release a new version at that time as all it does is piss off your customers.. If you cant upgrade your live store from one version to another, then that new version is only useful to new customers so no one at the point of release.. I completely understand that upgrade script can not be released on the same day as a new major version of OpenCart like it was from 1.4 to 1.5, but to say upgrading from 1.5.0.5 to 1.5.1 is not possible is just ridiculous.

Hope that instead of slagging me off, you will think about it and improve..

Thank you,
Igo

you only need to uninstall then click install on extension > modules. hardly the end of the world when you get to keep all you product, customer, order data.

you don;t have to reinstall shipping or payment extensions.

by **amertad** » Sun Jul 31, 2011 3:30 pm

Daniel wrote:
amertad wrote:hi .

auto complate in products (option+attributes) ..not works whit UTF8 chars...

thanks

which utf-8 characters?

i just tested it with ä and it works fine. are you typing the name of the global attributes?

thanx

by **b2bblack** » Mon Aug 01, 2011 11:03 am

Love 1.5.1.1! Really appreciate the hard work and effort you've put in to it. Wondered if there would be a way to have a check box for store pickup under delivery details? We are testing out using Open Cart to enter orders at our physical store since we can now login to a customers account from the admin area. Since we are located at the border of a state, when customers come from the adjoining state and we use their account (can't forget about those reward points), they would not be charged taxes unless we manually add the store address to their personal shipping addresses. A check box would make things much easier!

Thanks again for all your hard work!