Page 4 of 7
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Fri Apr 08, 2011 4:47 pm
by bcfl
Naturally you were right, I didn't realize the shipping by weight extension was a tier system I had
the extension enabled
the VAT disabled
the US enabled
once I reversed the VAT - US order it worked

Thank you for the help, sorry to cause any aggravation
bob
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Fri Apr 08, 2011 7:04 pm
by jubbbird
I reported a bug that affects the PayPoint payment module here:
http://forum.opencart.com/viewtopic.php?f=31&t=29889
I don't know if it affects the latest version because I'm a step behind, but I imagine the bug has been there for some time and it's quite unlikely someone else has already found it since the previous version was released.
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Sat Apr 09, 2011 12:03 am
by mcamca
SINik wrote:mcamca wrote:It is unclear from the above as to whether Packet, Airmail etc... prices will rise but some of these are already incorrect in:
catalog/model/shipping/royal_mail.php
so they need changing anyway!
As soon as Royal Mail make clear what all of the prices are I'll post the mods required for the above file!
Yet again shows how important it is to be able to alter these from admin!
---------------------------
I have an updated price guide from the post office, I've put the figures into the weight based shipping for the UK Shipping zone as follows:
.1:1.58,.25:1.96,.5:2.48,.75:3.05,1:3.71,1.25:4.90,1.5:5.66,1.75:6.42,2:7.18,4:8.95,6:12,8:15.05,10:18.1
This is for Packet size and first class only, this is far from ideal as I would like the option of sending by second class post as well.
Can anyone confirm that it is simply a case of creating new geozones based around shipping locations and applying them per size of product in the catalog to allow for the different sizes of shipping royal mail provide as well as changing the weight allowances to match the fact that second class stops at 1kg.
I'll have to do some serious brainstorming to make sure I cover all eventualities if that is the case.
If you want to carry on using the Royal Mail Shipping methods then:
I have produced a royal_mail.php as in v.1.4.9.4 with the rates valid as from 2011-04-04.
The file is available as a download from: REMOVED - OUT OF DATE! NEW PRICES 30TH APRIL 2012.
If you would prefer to read as a text file first you can view this from:
REMOVED - OUT OF DATE! NEW PRICES 30TH APRIL 2012.
You can copy the text file and save it in Notepad or Wordpad and save under "All files" as: royal_mail.php
(These files have notes included to explain any changes. Unless you know what your doing - LEAVE THEM ALONE!)
MAKE SURE YOU KEEP A COPY OF YOUR EXISTING royal_mail.php
and then upload the new one to:
REMOVED - OUT OF DATE! NEW PRICES 30TH APRIL 2012.
If you have problems then replace the new one with the copy of your existing/old one!
Hope this helps!
mcamca
PS. No doubt I'll hear if there are any problems!
----------------------------
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Sun Apr 10, 2011 7:05 pm
by qahar
Pagination on Specials page is not recognise special price based on customer group.
If we have 5 products, 1 product special for cust group default, and other for cust group merchant;
on special page, most visitor will see 1 product, but the pagination will show Showing 1 to 5 of 5 (1 Pages)
option_id in database changes on every update
Posted: Wed Apr 13, 2011 8:17 pm
by riku
Currently in v1.4.9.4 when you change an option for a product in the backend every option_id is changed for every product option. If I need to target a specific option with Javascript the code breaks on every update on the backend.
Re: Case sensitive on Mail address,OFFICIAL v1.4.9.4 BUG THR
Posted: Fri Apr 15, 2011 5:28 pm
by allenshea
You can register with same mail address with different case of letters.
Example,
info@website.com
Info@website.com
INFO@website.com
This isn't so good for the cart, make users confused when it can not login if they haven't type the right mail address.
Re: Case sensitive on Mail address,OFFICIAL v1.4.9.4 BUG THR
Posted: Sat Apr 16, 2011 4:43 am
by Qphoria
allenshea wrote:You can register with same mail address with different case of letters.
Example,
info@website.com
Info@website.com
INFO@website.com
This isn't so good for the cart, make users confused when it can not login if they haven't type the right mail address.
Good catch. Confirmed and fixed in next version
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 18, 2011 8:38 pm
by Harry Wedzinga
When creating an account and using the name 'Daniël' as first name something goes wrong. After saving, the special character 'ë' and everything behind it is ignored. I only see 'Dani'. In the backend there is no problem. I can use special characters there.
I tried to make an account on the demo with version 1.4.9.1 and there was no problem.
Harry Wedzinga
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 18, 2011 9:58 pm
by Qphoria
Harry Wedzinga wrote:When creating an account and using the name 'Daniël' as first name something goes wrong. After saving, the special character 'ë' and everything behind it is ignored. I only see 'Dani'. In the backend there is no problem. I can use special characters there.
I tried to make an account on the demo with version 1.4.9.1 and there was no problem.
Harry Wedzinga
That is weird. There was no changes to the way names were saved in any recent versions. Unless perhaps it is the auto-capitalization code.
Try this.
1. EDIT: catalog/model/account/customer.php
2. FIND:
Code: Select all
$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
3. REPLACE WITH:
Code: Select all
//$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
//$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 18, 2011 10:19 pm
by Harry Wedzinga
Qphoria wrote:Harry Wedzinga wrote:When creating an account and using the name 'Daniël' as first name something goes wrong. After saving, the special character 'ë' and everything behind it is ignored. I only see 'Dani'. In the backend there is no problem. I can use special characters there.
I tried to make an account on the demo with version 1.4.9.1 and there was no problem.
Harry Wedzinga
That is weird. There was no changes to the way names were saved in any recent versions. Unless perhaps it is the auto-capitalization code.
Try this.
1. EDIT: catalog/model/account/customer.php
2. FIND:
Code: Select all
$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
3. REPLACE WITH:
Code: Select all
//$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
//$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
------
That did the job, Thanks...
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Wed Apr 20, 2011 4:10 pm
by furyfire
Email encoding still broken for Thunderbird
When sending emails from the Admin panel email shows up blank when using Thunderbird as email client.
I've tried using various version of system/library/mail.php including the newest version from SVN.
Mail displays fine in other clients i've tested - iOS/Gmail.
I've also tried the
$header .= $this->newline;
fix without any success. Running the messages through validations seems to narrow it down to encoding issues.
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Fri Apr 22, 2011 4:53 am
by saabmosare
Harry Wedzinga wrote:Qphoria wrote:Harry Wedzinga wrote:When creating an account and using the name 'Daniël' as first name something goes wrong. After saving, the special character 'ë' and everything behind it is ignored. I only see 'Dani'. In the backend there is no problem. I can use special characters there.
I tried to make an account on the demo with version 1.4.9.1 and there was no problem.
Harry Wedzinga
That is weird. There was no changes to the way names were saved in any recent versions. Unless perhaps it is the auto-capitalization code.
Try this.
1. EDIT: catalog/model/account/customer.php
2. FIND:
Code: Select all
$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
3. REPLACE WITH:
Code: Select all
//$data['firstname'] = ucwords(strtolower(trim($data['firstname'])));
//$data['lastname'] = ucwords(strtolower(trim($data['lastname'])));
------
That did the job, Thanks...
Got the same problem in my adress fields when creating acount only. Swedish specialleters, so it might be good to change them all.

Done so myself and now it works well.
Must be a problem with all specialletters.
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Fri Apr 22, 2011 10:08 pm
by jang1200
You must change :
to :
...
for example :
Code: Select all
$data['firstname'] = ucwords(mb_strtolower(trim($data['firstname']), 'UTF-8'));
$data['lastname'] = mb_strtoupper(trim($data['lastname']), 'UTF-8');
$data['company'] = trim($data['company']);
$data['address_1'] = ucwords(mb_strtolower(trim($data['address_1']), 'UTF-8'));
$data['address_2'] = ucwords(mb_strtolower(trim($data['address_2']), 'UTF-8'));
$data['city'] = mb_strtoupper(trim($data['city']), 'UTF-8');
$data['postcode'] = trim($data['postcode']);
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Sat Apr 23, 2011 2:09 am
by Qphoria
jang1200 wrote:You must change :
to :
...
for example :
Code: Select all
$data['firstname'] = ucwords(mb_strtolower(trim($data['firstname']), 'UTF-8'));
$data['lastname'] = mb_strtoupper(trim($data['lastname']), 'UTF-8');
$data['company'] = trim($data['company']);
$data['address_1'] = ucwords(mb_strtolower(trim($data['address_1']), 'UTF-8'));
$data['address_2'] = ucwords(mb_strtolower(trim($data['address_2']), 'UTF-8'));
$data['city'] = mb_strtoupper(trim($data['city']), 'UTF-8');
$data['postcode'] = trim($data['postcode']);
Yea, the problem is that not all servers support "mb" libraries and for such a small feature, it is more likely this will be pulled from the core and you will have to add it as a mod to keep things more universal
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Sat Apr 23, 2011 6:32 pm
by jang1200
Qphoria wrote:Yea, the problem is that not all servers support "mb" libraries and for such a small feature, it is more likely this will be pulled from the core and you will have to add it as a mod to keep things more universal
Or maybe just :
Code: Select all
if( function_exists( 'mb_strtolower' )) {
$data['firstname'] = ucwords(mb_strtolower(trim($data['firstname']), 'UTF-8'));
...
...
}
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Sun Apr 24, 2011 1:26 am
by Qphoria
Yea that is a possibility too.. I didn't really want to .. but maybe it would be ok to have it
Another point about your signature that relates to this.. the filter_var function is oddly one that some hosts disable for some reason. Just good to know if we decide to use that for verification
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 25, 2011 11:05 am
by Qphoria
jang1200 wrote:
Or maybe just :
Code: Select all
if( function_exists( 'mb_strtolower' )) {
$data['firstname'] = ucwords(mb_strtolower(trim($data['firstname']), 'UTF-8'));
...
...
}
Think I found a better way:
Code: Select all
// Properly format customer details with Title case
if (function_exists('mb_convert_case')) {
$data['firstname'] = mb_convert_case(trim($data['firstname']), MB_CASE_TITLE, 'UTF-8');
$data['lastname'] = mb_convert_case(trim($data['lastname']), MB_CASE_TITLE, 'UTF-8');
$data['company'] = mb_convert_case(trim($data['company']), MB_CASE_TITLE, 'UTF-8');
$data['address_1'] = mb_convert_case(trim($data['address_1']), MB_CASE_TITLE,'UTF-8');
$data['address_2'] = mb_convert_case(trim($data['address_2']), MB_CASE_TITLE,'UTF-8');
$data['city'] = mb_convert_case(trim($data['city']), MB_CASE_TITLE, 'UTF-8');
$data['postcode'] = mb_convert_case(trim($data['postcode']), MB_CASE_UPPER, 'UTF-8');
}
Tested and working with the name used from this bug report:
http://forum.opencart.com/viewtopic.php ... ead#unread
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 25, 2011 5:00 pm
by jang1200
It is a very good solution. The only thing I would change is replice this:
$data['company'] = mb_convert_case(trim($data['company']), MB_CASE_TITLE, 'UTF-8');
to this:
$data['company'] = trim($data['company']);
The company name could be written on many ways, f.e. "COMPANY" , "CompanY", "CoMpanY", "F.H.U. 'company'" and we shouldn't change it, because everyone can call his own company the way he wish.
Code: Select all
public function convertCustomerData($data) {
$data['firstname'] = trim($data['firstname']);
$data['lastname'] = trim($data['lastname']));
$data['company'] = trim($data['company']);
$data['address_1'] = trim($data['address_1']);
$data['address_2'] = trim($data['address_2']);
$data['city'] = trim($data['city']);
$data['postcode'] = trim($data['postcode']);
if (function_exists('mb_convert_case')) {
$data['firstname'] = mb_convert_case($data['firstname'], MB_CASE_TITLE, 'UTF-8');
$data['lastname'] = mb_convert_case($data['lastname'], MB_CASE_TITLE, 'UTF-8');
$data['address_1'] = mb_convert_case($data['address_1'], MB_CASE_TITLE,'UTF-8');
$data['address_2'] = mb_convert_case($data['address_2'], MB_CASE_TITLE,'UTF-8');
$data['city'] = mb_convert_case($data['city'], MB_CASE_TITLE, 'UTF-8');
$data['postcode'] = mb_convert_case($data['postcode'], MB_CASE_UPPER, 'UTF-8');
}
return $data;
}
Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Mon Apr 25, 2011 9:40 pm
by Qphoria
jang1200 wrote:It is a very good solution. The only thing I would change is replice this:
$data['company'] = mb_convert_case(trim($data['company']), MB_CASE_TITLE, 'UTF-8');
to this:
$data['company'] = trim($data['company']);
The company name could be written on many ways, f.e. "COMPANY" , "CompanY", "CoMpanY", "F.H.U. 'company'" and we shouldn't change it, because everyone can call his own company the way he wish.
Fair enough

Re: OFFICIAL v1.4.9.4 BUG THREAD. POST ALL BUGS HERE
Posted: Wed Apr 27, 2011 8:50 pm
by Daz1847
Sorry if I have posted this in the wrong place but I cant find an answer anywhere about this.
This is very strange and I cant get my head around it at all
I am using both v1.4.9.3 on one website and v 1.4.9.4 on another.
This display error is on the Delivery Information page during checkout
With v1.4.9.3 the shipping address displays correctly like
Shipping Address
Dave blogs
52 Whatever street
Some Road
Reading RG1 9TP
Berkshire
United Kingdom
But in v1.4.9.4 it displays like this
Shipping Address
First Name = Dave
Last Name = Blogs
Company =
Address 1 = 52 Whatever Street
Address 2 = Some Road
City = Reading
Postcode = RG1 9TP
Zone = Berkshire
Zone Code = BERKS
Country = United Kingdom
I have been looking for ages and realy can't see why this is happening in v1.4.9.4
What am I missing
Anyone have any ideas?