Checkout not proceeding

[simonJae]

Hi Stan

.... ok... it is still happening - these "core...." files. What can you suggest?

The other modules/components I am running/have installed are "VMMigrator"; the template "GK_instyle" by Gavick; Chronoforms 5; MaxiMenu by Joomlack.fr; and "Customs filters" by Sakis Terz (breakdesigns.net) - nothing special or overloaded by any means.

Can you assist in getting this fixed?

Simon

PS: I will throw it at the VM forum and see if anyone has experienced the same

[simonJae]

RESOLVED

After much nail biting and your great assistance... the Alatek CreditCard Payment module was needed to be upgraded... and then after the caches had cleared... no further "CORE" files were being created.

Thanks for all your time and assistance Stan

Both a great component and superior support (might I add great patience and understand)

Thanks, Simon

[admin]

hello Simon, the "strict standards" are due to compatibility with upcoming php 5.6 and they are nice to fix, but it's not always that easy especially for Virtuemart's or Joomla's core files. They do not cause any specific problems, but it's known that once you get them all fixed, the php processor should be much faster. You can disable the strict notices within joomla's error reporting to "none" or within php fpm's config files. I am using this config on production:

php_admin_value[error_reporting] = E_ALL & ~E_STRICT & ~E_NOTICE & ~E_DEPRECATED

and this config on demos:

php_admin_value[error_reporting] = E_ALL & ~E_STRICT &~E_DEPRECATED


an example of the strict error is:

class TestClass {
function Test()
{
}
}

calling function statically with TestClass::Test(); results to the strict notice because the function is missing "static" declaration.

Especially artio sef used to have problems of using a function both in an object way:
$nc = new TestClass();
$nc->Test();

together with calling the same function statically
TestClass::Test();

best regards, stan

[simonJae]

hi Stan...

A couple of things... one is that error occurring with the quantity is fixed in VM2.9.9. - was that your doing? The huge "core.12345" files are no longer being generated

The main issue though, is the page has again gone blank with the upgrade (299). Can you have a quick look? I have turned OPC off at the moment - I have enough to contend with, with the addition of a new style sheet in VM.

ALSO - errors that were occurring through the sending of email to the Vendor... you won't believe if I told you... (maybe could be discussed on Skype) but it is in hand and will take a couple of days to remedy.

Your help would be appreciated - thanks.

BTW. Have put my hand up to the client to pay you : )

Simon

[admin]

hello simon, my guess is the the alatak CC plugin used an encryption function that was not stable on your php version.

are you having virtuemart 2.9.9b on joomla 3? i need to know more details about this. in general i do not suggest to run vm2.9.x on production sites yet because a stable version of virtuemart will be vm3 here. so you should be running vm2.6.10 (current stable on joomla 2.5) or vm2.9.9b (for testing on Joomla 3.x, this will become virtuemart 3)

if you decided to run vm2.9.9x you need to keep an eye on our download section as we release vm3 compatibility upgrades every week now.

regarding the emails - yes, the skype would be better. most email problems are caused by vendor misconfiguration or email misconfiguration within joomla. (you can check if this is email problem by using joomla's mass email feature).

best regards, stan,rupostel.com