Anyone else have this issue?
Using VM multilanguage, v3.2.2.
VMCUSTOM_ISTRAXX_DOWNLOAD_SUPPORTER & VMCUSTOM_ISTRAXX_DOWNLOAD_HELP dont get substituted in the backend and they get in the way on top of all other content.
tried to add some language substitution but no change...
Strange, ..... but just enter the vm config and store it again, it should update the message. It should be translated or at least show the normal english version (I just tested it). Maybe some hickup
hi, did what you said and its still the same.
since i updated to 3.2.3 and turned off the No Fallback switch, the text is back to normal again
its come back again... i updated to latest joomla! 3.7.5
I tried removing, saving and adding back the membership number but no joy.
Please write me a ticket here http://extensions.virtuemart.net/ticket with login data and I check myself.
done, thx
Man, this will be even mentioned in the release notes. I finally fixed even another problem, which was reported sometimes. The reason was, that I change the language in the plugin, according to the customer request, but the new language had not loaded the files, which were already loaded for the old language.
So I added now a new feature to the core, for developers. When we change the language now, it automatically loads all files for the new language, which were already loaded for the old language. I think that was a good discovery.
there is a serious mem leak in virtuemart 3.2.4 (official release) which has to be addressed:
how to reproduce:
edit your product details or other VM view and add a test code to produce an error:
for ($i=0; $i<20; $i++) {
if (!class_exists('VmConfig')) {
require(JPATH_ADMINISTRATOR.DIRECTORY_SEPARATOR.'components'.DIRECTORY_SEPARATOR.'com_virtuemart'.DIRECTORY_SEPARATOR.'helpers'.DIRECTORY_SEPARATOR.'config.php');
}
VmConfig::loadConfig();
$tag = JFactory::getLanguage()->getTag();
if (class_exists('vmLanguage')) {
if (method_exists('vmLanguage', 'setLanguageByTag')) {
vmLanguage::setLanguageByTag($tag);
}
}
}
the code above is used by many 3rd party extensions to load VM and the language properly...
after 16th round there is 128M fatal error (memory limit hit) and after cca 19th round you hit 512M ram
possible for to this problem:
edit:
\administrator\components\com_virtuemart\helpers\vmlanguage.php
find this code:
self::$_loaded['com'][$site][] = $name;
and replace with:
self::$_loaded['com'][$site][$name] = $name;
this code prevents memory build up upon repeatable calling of the function.
best regards, stan
Thank you Stan for finding. Actually, need to be done for loadModJLang also self::$_loaded['mod'][$name] = $name;,
but actually
VmConfig::loadConfig();
$tag = JFactory::getLanguage()->getTag();
if (class_exists('vmLanguage')) {
if (method_exists('vmLanguage', 'setLanguageByTag')) {
vmLanguage::setLanguageByTag($tag);
}
}
I do not see any reason to use vmLanguage::setLanguageByTag($tag); loadConfig does this already, just called vmLanguage::initialise();
So yes there is a memory leak, found by you and easily to fix, but you should also consider that your way with the language is not the normal way. The normal way is just to load the config.
should we wait to apply 3.2.4 in that case ?
Quote from: aftertaf on August 26, 2017, 13:23:26 PM
should we wait to apply 3.2.4 in that case ?
I have the same question. Since I am not a programmer, I prefer to apply a version without known issues that need immediate repair. Is a new version beyond 3.2.4 eminent?
Usually this call is done 1-2 times per page call. In the checkout, it can be called up to 4 times. The function sets the language. It is normally done 1 time per page call. Only when you change the language or when you change an orderstatus, then it can happen that the emails are sent in different languages. So theoretically it could be 6 times. Or when a plugin changes also the language 8 times. The problem starts to arise when the function is called more than 16 times. It is a real problem, when it is called more than 25 times. When it is called 32 times, a normal server cant handle it.
But Stan is the only one who used
if (method_exists('vmLanguage', 'setLanguageByTag')) {
vmLanguage::setLanguageByTag($tag);
}
He used it always, when he loaded the vm api. It was never meant that way.
So it is a problem only for people who use Rupostels OPC or so. And as far as I know, there should be a patch/new version of Rupostels.
The core problem is fixed already and will be soon in the svn, but no reason to make a new release.