VMCUSTOM_ISTRAXX_DOWNLOAD_SUPPORTER getting in the way

Started by aftertaf, July 21, 2017, 16:36:27 PM

Previous topic - Next topic

aftertaf

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...

Milbo

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
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

aftertaf


aftertaf

since i updated to 3.2.3 and turned off the No Fallback switch, the text is back to normal again

aftertaf

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.

Milbo

Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/


Milbo

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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

stAn99

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
----
RuposTel.com
www.rupostel.com
Your customized checkout solution for Virtuemart

Milbo

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 I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

aftertaf


Allen_K

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?

Milbo

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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/