OpenCart 1.5.4 Bug Thread

Not related just to this version, happens on all 1.5.

SEO url's do not work when in maintenance mode. They really do need to else you get penalised for duplicate content (once you come out of maintenance mode, google will access the site via both links).

Quick fix:

index.php

change: to: (swap them round)


catalog/controller/seo_url.php

change: to:

Thx

ADD Creative wrote:

sysiz wrote:

dklnd wrote:lowercase tags can also not be searched, I downloaded the 1.5.4.1 version 2 days ago.

Having same issue. One tag with 12 lowercase characters does not works most tags works fine.

How many products does the tag appear on? If a tag is on more than 50% of the products it may be ignored due to the MySQL MATCH function.

Yes, this seems to be the case. Will try the reverting workaround in few days.

SSL admin edit order problem:
Whenever I try to edit an order I get an "error" popup, and the "please wait" header hangs.
Nothing showing up in the error logs. Running 1.5.4.1.

My fix, I manually change https:// to http:// in address bar, the error is gone and I can edit my order.

When customer clicks "Reorder" button in Order History and there are products with option type image in order, products are added to cart without these options.

This solution works for me:

Find in catalog/controller/account/order.php Replace

Not strictly a bug with Opencart itself, but one that will affect mods/extensions that try to pass an array through the URL.

To fix:
In catalog/controller/common/seo_url.php, replace: with:

Another one that's only going to affect mods/extensions, this time if they add anything to the lookup query in the product getProducts function.

Because the OR group that checks for "model/sku/upc/etc,." is not enclosed in brackets, anything that is added to the query after it can be overridden.

To fix:
In catalog/model/catalog/product.php, replace: with: then replace: with: This part of the file on github has changed since 1.5.4.1 so this one may already be fixed.

Hello There,
We have the latest version of opencart , however it seems the Gift Voucher is not working.
When we create a new voucher and make it enabled , when we use it in the front end it gives warning:
Warning: Coupon is either invalid, expired or reached it's usage limit!

Same scenario when a customer purchase and right away use it in order to make a discount on an upcoming order ..
We have made Gift vouchers ENABLED in order totals as well.

What can be the reason?

How are we able to fix it?

Thanks.

Milad.

Opencart 1.5.4.1.
Not really a bug, but Ive not found some countries for adresses.
Those missing are: Perhaps others too, the reference is : ISO_3166-1

gob33 wrote:Opencart 1.5.4.1.
Not really a bug, but Ive not found some countries for adresses.
Those missing are:

Code: Select all

INSERT INTO `oc_country` (`country_id`, `name`, `iso_code_2`, `iso_code_3`, `address_format`, `postcode_required`, `status`) VALUES
(240, 'Aaland Islands', 'AX', 'ALA', '', 0, 1),
(241, 'Guernsey', 'GG', 'GGY', '', 0, 1),
(242, 'Isle of Man', 'IM', 'IMN', '', 0, 1),
(243, 'Jersey', 'JE', 'JEY', '', 0, 1),
(244, 'Palestinian Territory, occupied', 'PS', 'PSE', '', 0, 1),
(245, 'St. Barthelemy', 'BL', 'BLM', '', 0, 1),
(246, 'St. Martin (french part)', 'MF', 'MAF', '', 0, 1),
(247, 'Timor-Leste', 'TL', 'TLS', '', 0, 1);

Perhaps others too, the reference is : ISO_3166-1

Some of these and others have been added to GitHub. https://github.com/opencart/opencart/bl ... encart.sql

Guernsey, Jersey have been added East Timor (Timor-Leste) was corrected. Isle of Man was added as part of the UK as it shares the same import tax system and postal codes and UPS, Fedex and DHL XML interfaces do not recognize IM as a country code.

Although some places have ISO codes they are not always recognised by shippers and payment gateways so adding them can cause problems. Aaland Islands, Palestinian Territory, occupied, St. Barthelemy, St. Martin have ISO codes assigned but they may not be in use yet. They certainly need adding if they are actually in use.

Sure they are. BL, MF are destinations for tourists with luxury shops and hotels.

gob33 wrote:Sure they are. BL, MF are destinations for tourists with luxury shops and hotels.

It the ISO codes that are not in active use, not the actual locations.

For example the code MF is not recognized by PayPal or WorldPay as a country code, it is also not recognised by Fedex, UPS or DHL.
https://cms.paypal.com/us/cgi-bin/?cmd= ... ntry_codes
http://www.worldpay.com/support/kb/bg/h ... la003.html

So while a customer could select the country MF they would most likely not be able to check out with common payment and shipping modules.

ISO 3166 also list MF as a subdivision of FR (France). MF is also part of the France inside the EU, but is not part of the EU VAT zone. There are some other locations that share this status that are not added as countries but as zones in OpenCart.

If these newer codes are added the payment and shipping modules need to be updated as well to handle all the exceptions.

My problem is that the french shipping modules i wrote do have BL, MF, Guernsey, ... but customers of these countries cant register their address. They use French Post on french territory and not DHL, UPS, Fedex. If a payment module dont have these countries, it should warn on checkout and customer choose another one (check, COD).

Second, the french zones in OC 1.5.4.1 are false and incomplete. Comes from osCommerce and never has been updated.
A problem is you cant add lines without shifting others countries zones IDs to keep order.
I would have been clever to put a space of 50 or 100 ID numbers between countries in table 'zone'.

gob33 wrote: A problem is you cant add lines without shifting others countries zones IDs to keep order.
I would have been clever to put a space of 50 or 100 ID numbers between countries in table 'zone'.

These numbers are assigned by the db automatically. They are for internal indexing only and there is nothing wrong with just adding your new ones to the end and use NULL in place of the number to allow it to autoincrement. Sorting it still done by name in the code so you don't need to worry that the numbers are different.

gob33 wrote:My problem is that the french shipping modules i wrote do have BL, MF, Guernsey, ... but customers of these countries cant register their address. They use French Post on french territory and not DHL, UPS, Fedex. If a payment module dont have these countries, it should warn on checkout and customer choose another one (check, COD).

Second, the french zones in OC 1.5.4.1 are false and incomplete. Comes from osCommerce and never has been updated.
A problem is you cant add lines without shifting others countries zones IDs to keep order.
I would have been clever to put a space of 50 or 100 ID numbers between countries in table 'zone'.

It does look like AX, BL and MF need to be added as countries, the others are already done in the next version. Also some extra code needs writing for some of the payment and shipping modules to translate the new ISO codes (for example BL and MF need converting FR to get some modules to work).

A few weeks back I did submit some changes to the zones for France for the next version. I changed the code FX (France, Metropolitan) to FR and deleted FR and all its zones, as the zones under FX look like the right ones. You probably know a bit more about it, If you look at the links below and see what you think.

https://github.com/opencart/opencart/pull/116/files
https://github.com/opencart/opencart/bl ... encart.sql

Affiliate priority of cookie.
As metioned on http://forum.opencart.com/viewtopic.php ... 4&p=343222

This would be the default behaviour of the affiliate system or that would be changed in later versions of Opencart?
I mean, will the first affiliate get the comission against the last affiliate link or maybe, as most of affiliate systems, the last affiliate link delete the previous one?

I need to know to explain it to my affiliates.

@ADD creative: No, FR code is absolutely necessary.
FX code has been removed from ISO-3166 recently but you can keep it for compatibility.

I put here the SQL script I use for installing correct french zones in OC 1.5.4.1.
The script do a shift of table 'zone' for insertion.
I prefixed field 'code' with 'FR-' so that it is unique inside 'zones' and can be used as a key.
BL, MF have a country code which doesnt exist at present.

gob33 wrote:@ADD creative: No, FR code is absolutely necessary.
FX code has been removed from ISO-3166 recently but you can keep it for compatibility.

I put here the SQL script I use for installing correct french zones in OC 1.5.4.1.
The script do a shift of table 'zone' for insertion.
I prefixed field 'code' with 'FR-' so that it is unique inside 'zones' and can be used as a key.
BL, MF have a country code which doesnt exist at present.

I have not removed FR. I have removed FX as this caused incompatibilities with payment and shipping modules. It also confuses customers having France listed twice. What I want to know is, should the zones for France (FR and not including overseas parts) use the regions or departments. My understanding is it's the departments, this is also what Magento uses.

You put FR in 74. Let it as it was before FR=73, FX=74.
Can pose problem when transfering a shop from osCommerce/ ZenCart to OpenCart.
Both regions and depts, depends of users. Thats why it is interesting to have 73 and 74.
I put regions with 73, depts with 74, overseas as a country with 1 zone.

There only needs to be one country code for France, FR. Having two just causes problems when interfacing to other systems. There would be nothing to stop anyone from manually adding a country to import from osCommerce correctly. And it does not matter if FR is numbered 73 or 74. Just need to work out whether it is best to list the regions or departments, or both, as zones under the single country code for France.