Forums / Install & configuration / eZ CyberMut discussions
Pascal Specht
Tuesday 27 November 2007 4:47:30 am
This is the place to share technical details or questions concerning the eZ CyberMut extension.(see http://ez.no/community/contribs/workflow/ezcybermut)
Monday 03 December 2007 9:42:24 am
The error messages in the checker can be corrected this way to get more information about why a paiement was rejected:
$this->logger->writeTimedString('eZCyberMut : Post parameters were: '.$Verified_Result);
H-Works Agency
Wednesday 05 December 2007 10:06:03 am
Great Pascal !
I am gonna use this module right away.
EZP is Great
Wednesday 12 December 2007 12:34:02 pm
Hey Martin,
no news = good news? On our side the gateway is now in production since first of december, and we didn't have any problem so far, now with more than a hundred transactions...
Cheers,</Pascal>
Guillaume HH
Saturday 05 April 2008 1:59:34 am
Hi!
I'm looking for a "Société Générale" solution. Do you think I can upgrade your extension or I must to develop one "from scratch" ?
Thanks Guillaume
Saturday 05 April 2008 10:47:04 am
Hi Guillaume,
Société Générale is part of the SIPS/ATOS solution. Martin's ezSIPS extension will therefore fit your needs. eZCyberMut will not work.
</Pascal>
Tuesday 08 April 2008 3:29:07 am
Ok!Thanks for the correct extension's name!
++Guillaume
Friday 11 April 2008 4:13:01 am
Hi Pascal,
Don't you think we should use the "serialize" function to store our datas into "data_text_1" and "data_text_2" instead of the painful xml dom ?
I see only advantage with this technique :
- It use 2 lines of code to store & retrieve (serialize($array) | unserialize($field)) instead of tens of lines of codes and complexe functions for XML.
- It make our extension ezp 4.0 compatible by avoiding XML use.
- Its way more flexible as "serialize" can handle any kind of var type.
What do you think ?
Friday 11 April 2008 4:59:38 am
Hi Martin,
that would be definitively a smarter way to store data, I agree. In my case though I have many other places now where I rely on parsing a DOM inside the order's data_text fields, when building the invoice, tracking the shipping number, keeping track of downloads etc. Now that everything is in XML, I will have a hard time to unroll this. The other (small) advantage of having XML here is the human readeable format in logs and debug sessions.
I will have to look into this issue, but for the moment I did not decide to switch to version 4: I've seen too many issues with the new version to rely on it for production servers for the moment.
So in one word: People who don't rely on the XML storage should feel free to modify the extension's code to use the binary storage, it should work without problems. If I find some time I can also update the extension here to use your code.