Emails sent from admin panel aren't getting the language strings needed

[gripped]

The bug is discussed here http://forum.virtuemart.net/index.php?topic=123636.0

When I realised it was a bug I did not report it as it was suggested that it would be fixed in 2.6.0a. It isn't.

The fix / workaround is to link components/com_virtuemart/language/en-GB/en-GB.com_virtuemart.ini to language/en-GB/en-GB.com_virtuemart.ini (or just copy it there)

To reproduce.
Install  VirtueMart2.6.0a_Joomla_2.5.20-Stable-Full_Package.zip
Install the sample data
Make an order

The email sent to the customer will look like this


Server this was tested on

Code Select Expand

System Information
Setting Value

PHP Built On Linux www 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
Database Version 5.5.35-0+wheezy1
Database Collation utf8_general_ci
PHP Version 5.4.4-14+deb7u8
Web Server Apache/2.2.22 (Debian)
WebServer to PHP Interface apache2handler
Joomla! Version Joomla! 2.5.20 Stable [ Ember ] 30-April-2014 14:00 GMT
Joomla! Platform Version Joomla Platform 11.4.0 Stable [ Brian Kernighan ] 03-Jan-2012 00:00 GMT
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36

Code Select Expand

Relevant PHP Settings
Setting Value

Safe Mode Off
Open basedir None
Display Errors Off
Short Open Tags On
File Uploads On
Magic Quotes Off
Register Globals Off
Output Buffering Off
Session Save Path /var/lib/php5
Session Auto Start 0
XML Enabled Yes
Zlib Enabled Yes
Native ZIP Enabled Yes
Disabled Functions pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
Mbstring Enabled Yes
Iconv Available Yes

Code Select Expand

PHP Information
PHP Logo
PHP Version 5.4.4-14+deb7u8

System Linux www 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
Build Date Feb 17 2014 09:19:04
Server API Apache 2.0 Handler
Virtual Directory Support disabled
Configuration File (php.ini) Path /etc/php5/apache2
Loaded Configuration File /etc/php5/apache2/php.ini
Scan this dir for additional .ini files /etc/php5/apache2/conf.d
Additional .ini files parsed /etc/php5/apache2/conf.d/10-pdo.ini, /etc/php5/apache2/conf.d/20-curl.ini, /etc/php5/apache2/conf.d/20-gd.ini, /etc/php5/apache2/conf.d/20-mcrypt.ini, /etc/php5/apache2/conf.d/20-mysql.ini, /etc/php5/apache2/conf.d/20-mysqli.ini, /etc/php5/apache2/conf.d/20-pdo_mysql.ini
PHP API 20100412
PHP Extension 20100525
Zend Extension 220100525
Zend Extension Build API220100525, NTS
PHP Extension Build API20100525, NTS
Debug Build no
Thread Safety disabled
Zend Signal Handling disabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls
Registered Stream Filters zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, mcrypt.*, mdecrypt.*

[GJC Web Design]

Yes - the problem is missing entries in  components/com_virtuemart/language/en-GB/en-GB.com_virtuemart.ini

it is ~ 40 lines shorter than   language/en-GB/en-GB.com_virtuemart.ini

[Milbo]

Actually the problem is that the language is not correctly loaded there, because we use the old joomla mehtod. Please try the attached zip. It replaces two files which should load the correct language

[attachment cleanup by admin]

[gripped]

Tried it on my test site and it fixes the problem.
Only a quick test at the moment so I can't be sure it doesn't introduce any-more issues (I'll let you know if I find it does).

Surely this is quite a major bug. Unless I'm missing something it must be affecting everyone with a fresh install?

[Milbo]

We are going to update the installer soon. Actually it seems to be a problem for fresh installs and not updaters. yepp.

[gripped]

The cart modal box is looking in the wrong place as well

When the link from components/com_virtuemart/language/en-GB/en-GB.com_virtuemart.ini to language/en-GB/en-GB.com_virtuemart.ini is removed the cart model box is as below

[Milbo]

Please try this version http://dev.virtuemart.net/attachments/download/709/com_virtuemart.2.6.1_extract_first.zip

[gripped]

Sorry but that doesn't fix the issue with the modal.
With the link removed it still looked as in the image I posted. With the link in place it's fine.

edited to add
There are other places in the admin area I'd noticed language string issues. I've just linked all the language files in components/com_virtuemart/language/en-GB & administrator/components/com_virtuemart/language/en-GB/ back to language/en-GB/ and administator/ language/en-GB/ respectively and they have all gone away AFAICT.
I did this on test site with 2.6.1 and production on 2.6.0a

[gripped]

Sorry to say that still with 2.6.2 the modal is broken unless I have links to the old language file locations in place.

Links in place


Links removed

[jenkinhill]

I just did a fresh J2.5.20 installation and immediately installed VM2.6.2 with sample data. I added a main menu item to VM Front Page and then selected an item and added to cart. No language problem on the modal.

[attachment cleanup by admin]

[gripped]

Right I'll try another time with a fresh install.

I used a copy of my production site which is Joomla 2.5.20 , VM 2.6.0a and updated (with the joomla updater) to 2.6.2.

I don't mind have the links in place. I'm just letting you know as something seems wrong ?

[gripped]

Ok With a fresh install it worked as expected.

I don''t quite understand why it should make a difference but it does.

[Milbo]

I don't mind have the links in place. I'm just letting you know as something seems wrong ?

Yepp, thank you. Indeed one of the fixes should exactly prevent that. Seems I missed one case. It happens in messy installations. For example you have a multilingual page and some of the files are in the new location and some in the old. And some are translated and others not (and use the fallback). There are more combinations of this situation as you may expect.