Page 2 of 3

Re: Report bugs for Version 1.2.4 here

Posted: Fri Nov 26, 2010 10:15 am
by gob33
I looked at ZenCart to see how they manage amount formatting.
Table CURRENCIES incorporates decimal_point and thousand_point per currency

Code: Select all

DROP TABLE IF EXISTS currencies;
CREATE TABLE currencies (
  currencies_id int(11) NOT NULL auto_increment,
  title varchar(32) NOT NULL default '',
  code char(3) NOT NULL default '',
  symbol_left varchar(24) default NULL,
  symbol_right varchar(24) default NULL,
  decimal_point char(1) default NULL,
  thousands_point char(1) default NULL,
  decimal_places char(1) default NULL,
  value float(13,8) default NULL,
  last_updated datetime default NULL,
  PRIMARY KEY  (currencies_id)
) ENGINE=MyISAM;
Then display is done via a number_format(round($amount, ..., ...); with current default currency.
Its's not language depending.
Alegro has (only):

Code: Select all

CREATE TABLE IF NOT EXISTS `currency` (
  `currency_id` int(11) NOT NULL auto_increment,
  `title` varchar(32) collate utf8_unicode_ci NOT NULL default '',
  `code` varchar(3) collate utf8_unicode_ci NOT NULL default '',
  `symbol_left` varchar(12) collate utf8_unicode_ci default NULL,
  `symbol_right` varchar(12) collate utf8_unicode_ci default NULL,
  `decimal_place` char(1) collate utf8_unicode_ci default NULL,
  `value` double(13,8) default NULL,
  `date_modified` datetime default NULL,
  PRIMARY KEY  (`currency_id`)
) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
and depends of locale

Re: Report bugs for Version 1.2.4 here

Posted: Fri Nov 26, 2010 10:35 am
by Brent
Alegro uses formatting code as well, just different.

Code: Select all

$string .= number_format(round($value, $decimal_place), $decimal_place, (($format) ? $this->language->get('decimal_point') : '.'), (($format) ? $this->language->get('thousand_point') : NULL));
The difference is the language verses local.
I believe the thought was if you have a locale that has multiple languages that may use different format to display currency,
using language allows that.
For instance, Quebec in Canada is a mix of French and English, with many other sub cultures.
In that one locale, French use one format and English use another.
Each method has good points and bad. It's hard to find the right solution for everyone.
In either case, I think your rounding problem would still be there.
By the way, does your setup have a problem with currency rounding.

Re: Report bugs for Version 1.2.4 here

Posted: Fri Nov 26, 2010 11:20 am
by gob33
My only pb was 11] bar graph not corectly displayed. I changed that line to number_format.
Amounts in orders are displayed correctly on scren when i switch English <-> French.
Only some totals have a thousand_separtor of '.' instead of ' '

Re: Report bugs for Version 1.2.4 here

Posted: Sun Nov 28, 2010 9:38 am
by gob33
12] ALEGROCART-1.2.4\upload\admin\template\default\css\default.css
I changed line 327 to have a nice display for server infos:

Code: Select all

#phpinfo .a, #phpinfo .b {
	margin: 20px;
	padding: 10px;
}

#phpinfo table, td, tr {font-family: sans-serif; font-size: 11px; text-align: left;}
#phpinfo .p {text-align: center;}
#phpinfo .e {background-color: #ccccff; font-weight: bold; font-size: 11px;}
#phpinfo .h {background-color: #9999cc; font-weight: bold; font-size: 11px;}
#phpinfo .v {background-color: #cccccc; font-size: 12px;}
#phpinfo i {color: #666666; font-size: 11px;}
#phpinfo hr {display: none; font-size: 11px;}

Re: Report bugs for Version 1.2.4 here

Posted: Tue Nov 30, 2010 11:05 am
by gob33
13] Im not a specialist of collation but table 'product_discount' is the only one with COLLATE=utf8_bin.
Is it an error ?

Re: Report bugs for Version 1.2.4 here

Posted: Tue Nov 30, 2010 1:38 pm
by Brent
Could be. I wondered about that myself several times, but never had time to check why it was done that way.
Discount was originally a fixed amount, so it did not make sense to me. I changed it to be a percentage to allow more consistent discounts if special pricing is also applied. Neither should require that collation. It is normally used for binary files.

Re: Report bugs for Version 1.2.4 here

Posted: Fri Dec 03, 2010 10:40 pm
by Beachgirl
Sending e-mail through Admin is not working. Everything appears to be working as normal and I receive the "message has been successfully sent" but its not sending out the emails.

Admin mail settings are set to yes with the correct email address
Order Confirmations and Updates are Sending Mail Properly

Re: Report bugs for Version 1.2.4 here

Posted: Sat Dec 04, 2010 5:50 am
by Brent
I just tried it here and works fine.
Are you sending to a different Email address. Give some particulars send from / send to.

Re: Report bugs for Version 1.2.4 here

Posted: Sat Dec 04, 2010 11:50 am
by Beachgirl
I found the problem ... the mail is going straight into people's spam folders - this is a gmail issue.

One other question regarding Addresses. For USA, the address set up should look like:
Address 1
Address 2
City
Region/State
Country

I have modified all the files to reflect this when a customer is creating a account and changing address's but cant find the correct files to change the display, for example checkout and invoice shipping address.

I would also love it for the Newsletter Subscribe radio button be set to "Yes" on account setup rather than "No"

Re: Report bugs for Version 1.2.4 here

Posted: Sat Dec 04, 2010 12:15 pm
by Brent
Sorry, I haven't got to the address format problem yet.
We'll put it on the agenda for this version upcoming. I don't like it now either.

As far as the newsletter, we could add a setting in admin to allow the choice.
I would suggest checking your privacy laws. In Canada, if the customer does not explicitly select the choice to receive mails,
the merchant can be held in breach of privacy violation. They need to turn on the permission for us to send them mails.
It can also be classified as spamming.