OpenCart 1.5.1.3 Bug Thread

sean wrote:I greatly appreciate if someone make this clear for me:

Does the official release zip file come with latest bug fixes, or do I need to get the SVN to get the fixes.

How often fixes are updated from SVN, in the official release files?

The SVN has all the bug-fixes for the current official 1.5.1.3 zip. The problem is that the SVN also contains new and unfinished code, so it is useless.

robster wrote:

The SVN has all the bug-fixes for the current official 1.5.1.3 zip. The problem is that the SVN also contains new and unfinished code, so it is useless.

Indeed, although I think sean was asking if when bugs are found and fixed if the 1.5.1.3 zip file is then updated with the bug fixes. I would assume that it isn't or it would be given a new number??

robster

Daniel wrote:

innuoluke wrote:Hi,

I build a lot of OC sites for clients, and there has been a "bug" lingering for a while which I fixed for myself in previous versions of OC, but now the code has all changed (only just upgraded to OC > 1.5) and I really cba to go fix it again, so I thought I would see if this was actually a bug (in which case please can you guys fix it!), or if this was deliberately coded this way....

OK... we have a top level category (ID: 5) and a child category (ID: 10).
We give the top level category a nice SEO name of "Laptops".
We don't bother adding a SEO name to the child category.

When the "categories" menu is generated, the parent category link gets the href "mysite.com/Laptops" - correctly
When we visit the "Laptops" category, the child page now has the same href e.g. "mysite.com/Laptops" - incorrectly?!

I would expect the child page to have a link more like "mysite.com/index.php?route=product/category&path=5_10" as it doesn't have a SEO name.

The thing I am wondering is whether this is actually a bug (which I think / hope it is), or is this a deliberate action trying to force people to add SEO URLs to every category / product if SEO URLs is turned on (I hope not - that would be super-dirty-coder behaviour!!!) ?

Please could someone let me know if this is a bug or not, and how to fix it if so

its not a bug. just make sure you have seo keywords for all your categories if you are using seo urls.

In the older versions of OC ( < 1.5 ) the file I changed was /catalog/model/tool/seo_url.php - this file has disappeared in the new versions, so where has that code been migrated to?

JNeuhoff wrote:For a 2 language scenario, e.g. English and Swedish, it is noit possible to use English as the admin language and Swedish as the default frontend language. When using English as the admin language, no products nor categories are shown, when using Swdish as the admin language, all products show up just fine in the admin backend.

In general, I think the admin language should have no bearing on whether or not the products or categories are listed in admin backend, they should always be listed.

Terrence wrote:When trying in the online demo (not sure if it's already 1.5.1.3)

When you go to checkout and follow all steps (as guest) to make an order.
It will show the needed TAX, but when you modify one of the previous steps by clicking on modify
BUT not changing anything... the TAX disappears in the last step and you can complete your order TAX free.

Daniel wrote:

JNeuhoff wrote:For a 2 language scenario, e.g. English and Swedish, it is noit possible to use English as the admin language and Swedish as the default frontend language. When using English as the admin language, no products nor categories are shown, when using Swdish as the admin language, all products show up just fine in the admin backend.

In general, I think the admin language should have no bearing on whether or not the products or categories are listed in admin backend, they should always be listed.

yes it is. you set the store language top swedish and the admin language to english.

you have not done something properly.

maybe you did a bad backup and restore. when you create a new language it copies all the default language and adds it to the to the new language then you translate manually.

WHERE pd.language_id = '" . (int)$this->config->get('config_language_id') . "'"

$config->set('config_language_id', $languages[$config->get('config_admin_language')]['language_id']);

Daniel wrote:

Qphoria wrote:

Daniel wrote: declaring functions in side of classes is not the way to do things!

try this:

uasort($quote_data, array($this, 'comparecost'));

But then where should I put the actual compare function?
Maybe a new helper class?

create a method in the extension.

http://code.google.com/p/opencart/source/detail?r=663

adwordsvouchersshop wrote:

Daniel wrote:

adwordsvouchersshop wrote:I also saw this errors when i access the index.php?route=checkout/confirm of any store, including demo.opencart.com.
Have a look: http://demo.opencart.com/index.php?rout ... ut/confirm. I also get them on my store.

Code: Select all

Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 120Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 121Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 122Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 123Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 124Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 125Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 126Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 127Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 128Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 129Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 130Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 131Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 185Notice: Undefined variable: payment_address in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 185Notice: Undefined index: comment in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 259Notice: Undefined index: customer_id in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: customer_group_id in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: firstname in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: lastname in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: email in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: telephone in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: fax in /home/opencart/public_html/demo/catalog/model/checkout/order.php on line 4Notice: Undefined index: payment_method in /home/opencart/public_html/demo/catalog/controller/checkout/confirm.php on line 358Error: Could not load controller payment/!

i'll look into this.

Have you managed to get them fixed? Don't want to rush you, just asking.

utrdbaeu wrote:Not sure this is a bug or just an enhancement (to us it's a bug because we have non-ASCI alphabet):

Problematic code from "catalog/controller/product/manufacturer.php" - line 228:

Code: Select all

'description' => substr(strip_tags(html_entity_decode($result['description'], ENT_QUOTES, 'UTF-8')), 0, 100) . '..',

If there is any html entity around position 100 like:

Code: Select all

96 chars to here » bla bla

...that html entity is cut:

Code: Select all

96 chars to here &ra

We propose that substr and mb_substr get replaced with something like this:

Code: Select all

function MY_substr($string,$start,$length) {
	preg_match('#^\s*(.{'.$length.',}?)\s+.*$#s', $string, $matches);
	return $matches[1];
}


'description' => MY_substr(strip_tags(html_entity_decode($result['description'], ENT_QUOTES, 'UTF-8')), 0, 100) . '..',

Br

i2Paq wrote:

sean wrote:I greatly appreciate if someone make this clear for me:

Does the official release zip file come with latest bug fixes, or do I need to get the SVN to get the fixes.

How often fixes are updated from SVN, in the official release files?

The SVN has all the bug-fixes for the current official 1.5.1.3 zip. The problem is that the SVN also contains new and unfinished code, so it is useless.

utomo wrote:

i2Paq wrote:

sean wrote:I greatly appreciate if someone make this clear for me:

Does the official release zip file come with latest bug fixes, or do I need to get the SVN to get the fixes.

How often fixes are updated from SVN, in the official release files?

The SVN has all the bug-fixes for the current official 1.5.1.3 zip. The problem is that the SVN also contains new and unfinished code, so it is useless.

When we can expect new version will be released ?
Thankyou

i2Paq wrote: From what I see it will take another 2 weeks to get 1.5.2 finished. Then it needs a test-run to get the bugs out and hopefully we get a "stable" 1.5.2.1 release a week or 2 after the test-run.