Mollie with Event payment: Serialization of 'Closure' is not allowed #17

magnolia61 · 2016-06-20T14:47:31Z

Not sure if this is Mollie specific but in civicrm 4.7 our working Mollie implementation stopped working for event registrations (regular contributions still work ok).

Sorry, there was an error processing your payment. Please try again later.
Exception: Serialization of 'Closure' is not allowed in serialize() (line 162 of /home/xyz/domains/onvergetelijk.nl/public_html/civisand/sites/all/modules/civicrm/CRM/Core/BAO/Cache.php).
Uncaught exception thrown in shutdown function.

Exception: Serialization of 'Closure' is not allowed in session_write_close() (line 3501 of /home/xyz/domains/onvergetelijk.nl/public_html/civisand/includes/bootstrap.inc).

I tested this with civicrm 4.7.0, 4.7.8 and the current master code (~4.7.9).
I am trying to do some further tests but at this moment have no clue which haystack to start searching the needle in (symfony? php session settings? core code difference for contributions and events?)

phpMyAdmin civicrm_system_log says:

unknown processor error omnipay_Mollie
["Serialization of 'Closure' is not allowed"]

Fall Fundraiser Diner on 4.7.0 with sandbox demo data and Mollie Test config (will simulate payment)
https://civisand.onvergetelijk.nl/civicrm/event/register?reset=1&id=1
Working demo on 4.6.18 (simulates payment, no real payment is made)
https://civilongterm.onvergetelijk.nl/civicrm/event/register?reset=1&id=71

eileenmcnaughton · 2016-06-20T18:48:31Z

Are you able to put some debug in to find out what is being passed to CRM/Core/BAO/Cache.php in the $data value?

public static function setItem(&$data, $group, $path, $componentID = NULL) {

magnolia61 · 2016-06-21T06:39:53Z

Not sure how where to put what code to debug the $data value being passed. Can you help me with the proper code to debug this? I can apply it to 4.6.18/4.7.8 & master with working Mollie ipn feedback.

BTW Using civicrm's own debgging I can see the step just before the error is:
CRM_Core_Payment_OmnipayMultiProcessor->doDirectPayment(Array, 'event')
in /CRM/Core/Payment/OmnipayMultiProcessor.php:421 (doTransferCheckout)
if (!empty($params['token'])) {return;} throw new CRM_Core_Exception('Payment redirect failed');}

eileenmcnaughton · 2016-06-21T07:02:29Z

you can stick in some code like

echo "<pre>";
print_r($data);
die;

TEMPORARILY!

magnolia61 · 2016-06-21T07:04:21Z

In the cache.php file in the setitem function?

eileenmcnaughton · 2016-06-21T08:05:41Z

yep

eileenmcnaughton · 2016-06-21T08:06:01Z

don't leave it on prod for more than a moment though - it will break things

magnolia61 · 2016-06-21T13:48:28Z

I had to uncomment the die; to get to the error screen.

public static function setItem(&$data, $group, $path, $componentID = NULL) {
    echo "<pre>debug:data:<br>";
    print_r($data);
    //die;

But succeeded in retrieving the debug data as attached in enclosed txt file.
debug_data.txt
Probably good to emphasize regular contributions works ok, but the event registration gives this error.

magnolia61 · 2016-12-08T16:13:28Z

Still struggling with this one. A few civicrm versions further (4.7.14) and Omnipaymultiprocessor version 1.9 we still have the exact same behaviour on production and out-of-the-box new install dev-site:

regular contributions run fine, mollie is activated and the callback functions perfectly.
event registrations run into a fatal error just before going to the mollie screen

I don't know where to go from here, and I wonder if someone could read something usefull in my previously submitted debug data.

Any advice? What could cause a "Serialization of 'Closure'" error anyway?

magnolia61 · 2016-12-12T16:16:37Z

OK, got a little further with debugging:
The valua of $data in CRM/Core/BAO/Cache.php that throws an error when serialized is:

Array
(
    [defaults] => Array
        (
        )

    [constants] => Array
        (
        )

    [values] => Array
        (
            [Register] => Array
                (
                    [qfKey] => 60b217c8aa3b27fef940a9e5e9b7fb55_7233
                    [entryURL] => https://civisand.onvergetelijk.nl/civicrm/event/register?reset=1&id=1
                    [first_name] => iemand
                    [last_name] => eennaam
                    [email-Primary] => user@localhost.net
                    [hidden_processor] => 1
                    [scriptFee] => 
                    [scriptArray] => 
                    [additional_participants] => 
                    [priceSetId] => 7
                    [price_8] => 16
                    [payment_processor_id] => 3
                    [bypass_payment] => 
                    [_qf_default] => Register:upload
                    [MAX_FILE_SIZE] => 134217728
                    [_qf_Register_upload] => Continue
                )

            [Confirm] => Array
                (
                    [qfKey] => 60b217c8aa3b27fef940a9e5e9b7fb55_7233
                    [entryURL] => https://civisand.onvergetelijk.nl/civicrm/event/register?reset=1&id=1
                    [_qf_default] => Confirm:next
                    [_qf_Confirm_next] => Continue
                )

            [ThankYou] => Array
                (
                )

        )

    [valid] => Array
        (
            [Register] => 1
            [Confirm] => 1
            [ThankYou] => 
        )

    [_qf_button_name] => _qf_Confirm_next
)

Now why would that cause the: Exception: Serialization of 'Closure' is not allowed in serialize() in CRM/Core/BAO/Cache.php) ?

magnolia61 · 2016-12-12T19:21:08Z

Some more info: the debug show a Closure Object (see attached debug file)
data-closure.txt
Would this be the 'closure' the error talks about?

eileenmcnaughton · 2016-12-22T04:09:19Z

This looks like the closure

[request.error] => Array
(
[0] => Array
(
[0] => Closure Object
(
[this] => Omnipay\Mollie\Message\PurchaseRequest Object
(
[endpoint:protected] => https://api.mollie.nl/v1
[parameters:protected] => Symfony\Component\HttpFoundation\ParameterBag Object
(
[parameters:protected] => Array
(
[apiKey] => test_aQF2sndGMUuj2VCP6qtkqccq33V4vc
[amount] => 50
[currency] => USD
[description] => 202-109-Fall Fundraiser
[transactionId] => 109
[clientIp] => 92.108.199.165
[returnUrl] => https://www.ourdomain.nl/civicrm/payment/ipn/3?
[cancelUrl] => https://www.ourdomain.nl/civicrm/event/register?reset=1&cc=fail&participantId=63
[notifyUrl] => https://www.ourdomain.nl/civicrm/payment/ipn/3?
[card] => Omnipay\Common\CreditCard Object
(
[parameters:protected] => Symfony\Component\HttpFoundation\ParameterBag Object
(
[parameters:protected] => Array
(
[billingFirstName] =>
[shippingFirstName] =>
[billingLastName] =>
[shippingLastName] =>
[email] => user@localhost.net
[billingAddress1] =>
[billingAddress2] =>
[billingCity] =>
[billingPostcode] =>
[billingState] =>
[billingCountry] =>
[billingPhone] =>
[billingCompany] =>
[shippingCompany] =>
[cvv] =>
[number] =>
)

                                                                                                            )

                                                                                                    )

                                                                                                [cardReference] => 
                                                                                            )

                                                                                    )

What strikes me about that is that a) you only experience it on event & b) it is in the error part of the guzzle http request object. I wonder if that key would not be there if some sort of error had not occurred

eileenmcnaughton · 2016-12-22T04:54:00Z

I tried it locally & I see that if I output $data in this function

<?php

namespace Omnipay\Mollie\Message;

use Omnipay\Common\Message\RedirectResponseInterface;

class FetchTransactionResponse extends AbstractResponse implements RedirectResponseInterface
{
    /**
     * {@inheritdoc}
     */
    public function isRedirect()
    {
//hack in debug
print_r($data);die;
        return isset($this->data['links']['paymentUrl']);
    }

I get

array (
  'error' => 
  array (
    'type' => 'request',
    'message' => 'The webhook location is invalid',
    'field' => 'webhookUrl',
  ),
)

Now in my case that is a totally valid error because I'm testing from a local user (ie. not a web accessible one) & Mollie is rightly rejecting it - but perhaps if you try similar debug you might get the actual error?

This prevents problems caching the object

eileenmcnaughton · 2016-12-22T05:12:38Z

If you apply the patch I just pushed you might get better error reporting

eileenmcnaughton · 2016-12-22T05:38:42Z

If you could try applying this (to 4.7.14) you would get a better error (& you could comment on the PR as to your testing to help it get merged)

civicrm/civicrm-core#9572

magnolia61 · 2016-12-22T20:16:29Z

BTW Trying to debug with print_r($data);die; in FetchTransactionResponse.php does not seem work with me (does not output on screen). But when I hashout the die();-part I get:
Notice: Undefined variable: data in Omnipay\Mollie\Message\FetchTransactionResponse->isRedirect() (line 15 of /home/xyz/domains/ourdomain.nl/public_html/sand/sites/all/modules/civicrm_extensions/nz.co.fuzion.omnipaymultiprocessor/vendor/omnipay/mollie/src/Message/FetchTransactionResponse.php).

eileenmcnaughton · 2016-12-23T00:50:08Z

Sorry - it should be $this->data

But before you do that - try this Omnipay patch as well #17

Also - did you comment on the Confirm.php patch to say you have tested it?

magnolia61 · 2016-12-23T07:41:15Z

Not sure which Omnipay patch you refer to (it link to this issue), but I was able to retrieve $this->data


Array
(
    [id] => tr_Pmtad5DtA2
    [mode] => test
    [createdDatetime] => 2016-12-23T07:30:35.0Z
    [status] => open
    [expiryPeriod] => PT15M
    [amount] => 50.00
    [description] => 203-124-Fall Fundraiser
    [method] => 
    [metadata] => Array
        (
            [transactionId] => 124
        )

    [details] => 
    [profileId] => pfl_mBc44wsnm5
    [links] => Array
        (
            [paymentUrl] => https://www.mollie.com/payscreen/select-method/Pmtad5DtA2
            [webhookUrl] => https://civisand.ourdomain.nl/civicrm/payment/ipn/3?
            [redirectUrl] => https://civisand.ourdomain.nl/civicrm/payment/ipn/3?
        )

)

magnolia61 · 2016-12-23T07:46:22Z

With the patched Confirm.php the fatal error is gone and a better error message is displayed:

Exception: "Serialization of 'Closure' is not allowed"

#0 (...)/CRM/Core/BAO/Cache.php(151): serialize((Array:37))
#1 (...)/CRM/Core/BAO/Cache.php(241): CRM_Core_BAO_Cache::setItem((Array:37), "CiviCRM Session", "CiviCRM_CRM_Event_Controller_Registration_60b217c8aa3b27fef940a9e5e9b7fb55_5462")
#2 (...)/CRM/Core/Session.php(530): CRM_Core_BAO_Cache::storeSessionToCache((Array:2), TRUE)
#3 (...)/CRM/Utils/System.php(1393): CRM_Core_Session::storeSessionObjects()
#4 (...)/CRM/Utils/System.php(442): CRM_Utils_System::civiExit()
#5 (...)/CRM/Event/Form/Registration/Confirm.php(1315): CRM_Utils_System::redirect("/civicrm/event/register?id=1")
#6 (...)/CRM/Event/Form/Registration/Confirm.php(820): CRM_Event_Form_Registration_Confirm->processPayment(Object(CRM_Core_Payment_OmnipayMultiProcessor), (Array:42))
#7 (...)/CRM/Core/Form.php(435): CRM_Event_Form_Registration_Confirm->postProcess()
#8 (...)/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
#9 (...)/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Event_Form_Registration_Confirm), "next", "Next")
#10 (...)/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Event_Form_Registration_Confirm), "next")
#11 (...)/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Event_Form_Registration_Confirm), "next")
#12 (...)/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
#13 (...)/CRM/Core/Invoke.php(310): CRM_Core_Controller->run((Array:3), NULL)
#14 (...)/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:15))
#15 (...)/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#16 (...)/drupal/civicrm.module(448): CRM_Core_Invoke::invoke((Array:3))
#17 /home/xyz/domains/ourdomain.nl/public_html/sand/includes/menu.inc(527): civicrm_invoke("event", "register")
#18 /home/xyz/domains/ourdomain.nl/public_html/sand/index.php(21): menu_execute_active_handler()
#19 {main}

Sorry but we are not able to provide this at the moment.
Serialization of 'Closure' is not allowed

Exception: Serialization of 'Closure' is not allowed in serialize() (line 151 of (...)/CRM/Core/BAO/Cache.php).

I commented on your PR for Confirm.php that it works nicely with me :-)

magnolia61 · 2016-12-23T07:54:09Z

BTW. Maybe this API-key helps :-) It is a test key of us: XXXXXXXXX (edited)

veelineen · 2017-01-25T22:07:01Z

not that it helps, but same problem here

eileenmcnaughton · 2017-01-26T05:09:46Z

OK -are you using

the core PR Mollie with Event payment: Serialization of 'Closure' is not allowed #17 (if so & you can see the advantage please comment on it to help get it merged)
the latest version of this extension (ie. from github rather than the tagged release)

Dietermartens · 2017-01-29T17:24:47Z

Same issue here... did you guys find anything yet?

eileenmcnaughton · 2017-01-30T01:11:30Z

Can you please confirm when reporting this that you are using 1) the latest version of this repo from github (including . 2) the PR mentioned in the comment above. I would expect it to change the error to not refer to serialization of closure but to display the actual error.

Dietermartens · 2017-01-30T15:31:07Z

Okay, so I've installed the module a few times now, from the repo (latest version).

I've also installed the patch of Confirm.php but that doesn't give me an error, just a redirect with fault message.

Thx!

magnolia61 · 2017-01-30T16:42:31Z

Same with me. I checked out the current master and patched the Confirm.php file. I do not see ugly error message anymore. Just the "Sorry, there was an error processing your payment" and the screen is redirected to the registration form.
Then again, looking at civicrm_syslog there still is:
unknown processor error omnipay_Mollie - ["Serialization of 'Closure' is not allowed"]

eileenmcnaughton · 2017-01-30T19:35:58Z

Richard what does your backtrace look like?

@Dietermartens - what is in your civicrm_system_log table.

In my tests this line

$this->gateway = NULL;

caused it to stop giving the serialisation of closure & give the real message

Dietermartens · 2017-01-31T13:15:35Z

I've got the exact same message as @magnolia61. But if I try now to enable the module, it shows this error.

Exception: "API error: 'payment_type' is not a valid option for field option_group_id"

#0 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(265): CRM_Core_ManagedEntities->onApiError("option_value", "create", (Array:8), (Array:6))
#1 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(168): CRM_Core_ManagedEntities->updateExistingEntity(Object(CRM_Core_DAO_Managed), (Array:4))
#2 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(141): CRM_Core_ManagedEntities->reconcileEnabledModule(Object(CRM_Core_Module), (Array:18))
#3 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(122): CRM_Core_ManagedEntities->reconcileEnabledModules()
#4 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(396): CRM_Core_ManagedEntities->reconcile()
#5 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Extension/Manager.php(242): CRM_Core_Invoke::rebuildMenuAndCaches(TRUE)
#6 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Admin/Form/Extensions.php(181): CRM_Extension_Manager->install((Array:1))
#7 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Form.php(435): CRM_Admin_Form_Extensions->postProcess()
#8 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
#9 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Admin_Form_Extensions), "next", "Next")
#10 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Admin_Form_Extensions), "next")
#11 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Admin_Form_Extensions), "next")
#12 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
#13 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Page/Basic.php(384): CRM_Core_Controller->run()
#14 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Page/Basic.php(168): CRM_Core_Page_Basic->edit(1, NULL)
#15 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Admin/Page/Extensions.php(121): CRM_Core_Page_Basic->run()
#16 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(310): CRM_Admin_Page_Extensions->run((Array:3), NULL)
#17 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#18 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#19 /home/kogaopvang/domains/kogaopvang.be/public_html/sites/all/modules/civicrm/drupal/civicrm.module(448): CRM_Core_Invoke::invoke((Array:3))
#20 internal function: civicrm_invoke("admin", "extensions")
#21 /home/kogaopvang/domains/kogaopvang.be/public_html/includes/menu.inc(527): call_user_func_array("civicrm_invoke", (Array:2))
#22 /home/kogaopvang/domains/kogaopvang.be/public_html/index.php(28): menu_execute_active_handler()
#23 {main}

eileenmcnaughton · 2017-02-01T20:35:30Z

There should be a value in the civicrm_option_group table created on install

    array(
      'name' => 'payment_type',
      'entity' => 'option_group',
      'params' =>
        array(
          'version' => 3,
          'title' => 'Payment Type',
          'name' => 'payment_type',
          'description' => 'Payment Processor Payment type (configured on processor)',
          'is_reserved' => TRUE,
          'is_active' => TRUE,
        ),
    ),

This is either missing for you or it exists but some caching has prevented it from being picked up.

magnolia61 · 2017-02-01T20:52:42Z

@eileenmcnaughton Using the patched Confirm.php and the current master code (with $this->gateway = NULL; in PaymentExtended.php) I do not get a backtrace, only an error mesage (and the entry in system_log which still states: ["Serialization of 'Closure' is not allowed"])

eileenmcnaughton · 2017-02-01T23:39:12Z

I guess you need to put some debug in then to figure out where that is getting logged from.... Maybe if you put a print_r(debug_backtrace());die; right before where it sets $this->gateway to null it will still hit that - otherwise - we need to figure out where the debug needs to go. Perhaps in CRM_Utils_SystemLogger::log()

Dietermartens · 2017-02-02T09:32:52Z

There were a couple of tables who had managed to stay in the database, that was the reason for my error. So that works now, thx!

Okay so I've done that and i get this:
debug_array.txt

Dietermartens · 2017-02-02T09:53:53Z

And now with the custom confirm.php i get this message/ screen.

magnolia61 · 2017-02-02T15:05:14Z

@eileenmcnaughton On my staging site I was able to get a backtrace of the error. Syslog table stil mentions ["Serialization of 'Closure' is not allowed"]

eileenmcnaughton · 2017-02-03T03:03:09Z

Try editing CRM_Event_Registration_Confirm and after this line

catch (\Civi\Payment\Exception\PaymentProcessorException $e) {

add

print_r($e);
die;

To get the details about the error. It will probably be a long log and may contain confidential information (mollie account details) so you might want to redact it.

magnolia61 · 2017-02-04T00:14:24Z

I tried again with the debug lines at the end of Confirm.php on a local sandbox installation. It spit out the following while registering for the Fall Fundraiser Diner. (I have registered for that event so may times I actually would love to attend it now!) :-) Anyway, step by step we're nearer to finding the right haystack. Next the needle... (still amazing redirecting to Mollie works ok for regular contributions. It's the events that have the 'Serialization of 'Closure'' error)
PaymentProcessorException-Sand.txt

Dietermartens · 2017-02-04T21:24:25Z

I'm sorry but in which file can i find the CRM_Event_Registration_Confirm class?

magnolia61 · 2017-02-04T21:33:29Z

I believe Eileen meant the file CRM/Event/Form/Registration/Confirm.php :-)

eileenmcnaughton · 2017-02-05T21:55:00Z

I have just pushed a commit which unsets gateway before storing the session. It might help

magnolia61 · 2017-02-05T23:12:18Z

Hi Eileen, you found the needle in the haystack rationally. Emotionally it feels like you've found the Holy Grail :-) That said, the finish is in sight but there is still a small quirk.

With your latest patch:

Event registration with Mollie now redirects to the Mollie payment provider!!! Finally again!
When redirecting back to CiviCRM there is an error message:
The transactionReference parameter is required

You can see what happens at my following dev site with the sandbox database. It uses the test-api for Mollie. It simulates, but no real monetary transaction is made. Feel free to try.
https://civisand.onvergetelijk.nl/civicrm/event/register?reset=1&id=1

magnolia61 · 2017-02-05T23:39:42Z

Since the error: The transactionReference parameter is required was already present before we ran into the "Serialization of 'Closure' is not allowed" issue I believe this specific issue can be closed because it is solved by 9338069 We can continue solving the transactionReference error in #6 Thanks for your great help so far! I hope we can also nail the last bit and finally have Mollie available (it's great, you'll love it. The Dutch love it! I believe the Belgiums too! No monthly fee and low fares per transaction)

eileenmcnaughton · 2017-02-06T03:32:41Z

Ok - I'll close this in favour of the other as you suggest. I suspect the transactionReference might be that the invoice_id is not set or not passed to Mollie

Dietermartens · 2017-02-06T07:43:05Z

Hi Eileen, I'm sorry to say it, but I still have the same error.

Maybe you can do something with this error dump.

This is the output off the edited confirm.php

ps. Thx @magnolia61 :)
array_dump.txt

magnolia61 · 2017-02-06T08:23:44Z

@Dieter Let's mail on this. I am glad to help you replicate the steps I took. My mail is richard(dot)van(dot)oosterhout@gmail.com

veelineen · 2017-02-06T20:29:44Z

Yes! patch is working. Cancelling the payment doesn't give me the right page, but I can communicate about that with the user for now. Thanks for the fix!

eileenmcnaughton · 2017-02-15T08:59:40Z

Closing per discusson

adixon · 2017-05-01T17:40:16Z

I had this same error using a custom omnipay plugin (https://github.com/adixon/omnipay-bluepay), one that doesn't use transparent redirect, so I had to dig a little deeper. So far, my best guess is that there really is a problem with a closure object trying to get serialized and cached, it's not just a symptom. Unsetting the gateway before the explicit session save fixes one instance, but I'd guess this issue could easily recur in some form in other places, especially during error handling (which I assume is what you were trying to sort out?). From what I can see, the closure object is in the request.error of a sympony listener, so my conclusion is that the gateway would need to be explicitly removed as soon as it's no longer needed, or else you'd want to prevent it from getting attached to whatever is getting stuffed into the session (the contribution object, I assume), or else the guzzle object would need to be discardable itself. Or of course, since the guzzle library is now deprecated, updating to whatever is supposed to replace it might make the problem just vanish. Or we could fix the civicrm session cache code to exclude any objects containing closures, which might prevent future problems at the cost of some messy debugging if the object really needed to be cached.

eileenmcnaughton · 2017-05-02T05:59:00Z

Yep - the situation I was hitting was during error handling, but I actually think unsetting the gateway is probably good security practice too

magnolia61 changed the title ~~Mollie problem with Event payment: Serialization of 'Closure' is not allowed in serialize()~~ Mollie with Event payment: Serialization of 'Closure' is not allowed Jun 20, 2016

eileenmcnaughton added a commit that referenced this issue Dec 22, 2016

Remove gateway from object in error #17

3de622b

This prevents problems caching the object

eileenmcnaughton added a commit that referenced this issue Feb 5, 2017

#17 unset gateway before storing session

9338069

magnolia61 mentioned this issue Feb 5, 2017

Omnipay Mollie integration #6

Closed

eileenmcnaughton closed this as completed Feb 15, 2017

deputt mentioned this issue Oct 16, 2017

API error: 'payment_type' is not a valid option for field option_group_id #38

Closed

wannesderoy mentioned this issue Aug 3, 2018

Mollie with Event payment: Serialization of 'Closure' is not allowed when using Redis #55

Closed

mlutfy added a commit to coopsymbiotic/nz.co.fuzion.omnipaymultiprocessor that referenced this issue Feb 5, 2019

Applies eileenmcnaughton#17 for non-redirect processors.

e9b5459

mlutfy mentioned this issue Feb 5, 2019

Applies #17 for non-redirect processors. #73

Closed

cray146 mentioned this issue Jul 12, 2019

DB error on installation of the extension #123

Closed

timatidg mentioned this issue Jun 2, 2022

Database error upgrading to 3.15 #224

Open

Mollie with Event payment: Serialization of 'Closure' is not allowed #17

Mollie with Event payment: Serialization of 'Closure' is not allowed #17

Comments

magnolia61 commented Jun 20, 2016 • edited Loading

eileenmcnaughton commented Jun 20, 2016

magnolia61 commented Jun 21, 2016

eileenmcnaughton commented Jun 21, 2016

magnolia61 commented Jun 21, 2016

eileenmcnaughton commented Jun 21, 2016

eileenmcnaughton commented Jun 21, 2016

magnolia61 commented Jun 21, 2016 • edited Loading

magnolia61 commented Dec 8, 2016

magnolia61 commented Dec 12, 2016 • edited Loading

magnolia61 commented Dec 12, 2016

eileenmcnaughton commented Dec 22, 2016

eileenmcnaughton commented Dec 22, 2016 • edited Loading

eileenmcnaughton commented Dec 22, 2016

eileenmcnaughton commented Dec 22, 2016

magnolia61 commented Dec 22, 2016

eileenmcnaughton commented Dec 23, 2016

magnolia61 commented Dec 23, 2016 • edited Loading

magnolia61 commented Dec 23, 2016

magnolia61 commented Dec 23, 2016 • edited Loading

veelineen commented Jan 25, 2017

eileenmcnaughton commented Jan 26, 2017

Dietermartens commented Jan 29, 2017

eileenmcnaughton commented Jan 30, 2017

Dietermartens commented Jan 30, 2017 • edited Loading

magnolia61 commented Jan 30, 2017 • edited Loading

eileenmcnaughton commented Jan 30, 2017

Dietermartens commented Jan 31, 2017

eileenmcnaughton commented Feb 1, 2017

magnolia61 commented Feb 1, 2017

eileenmcnaughton commented Feb 1, 2017

Dietermartens commented Feb 2, 2017 • edited Loading

Dietermartens commented Feb 2, 2017

magnolia61 commented Feb 2, 2017

eileenmcnaughton commented Feb 3, 2017

magnolia61 commented Feb 4, 2017 • edited Loading

Dietermartens commented Feb 4, 2017

magnolia61 commented Feb 4, 2017

eileenmcnaughton commented Feb 5, 2017

magnolia61 commented Feb 5, 2017

magnolia61 commented Feb 5, 2017 • edited Loading

eileenmcnaughton commented Feb 6, 2017

Dietermartens commented Feb 6, 2017

magnolia61 commented Feb 6, 2017 • edited Loading

veelineen commented Feb 6, 2017

eileenmcnaughton commented Feb 15, 2017

adixon commented May 1, 2017

eileenmcnaughton commented May 2, 2017

magnolia61 commented Jun 20, 2016 •

edited

Loading

magnolia61 commented Jun 21, 2016 •

edited

Loading

magnolia61 commented Dec 12, 2016 •

edited

Loading

eileenmcnaughton commented Dec 22, 2016 •

edited

Loading

magnolia61 commented Dec 23, 2016 •

edited

Loading

magnolia61 commented Dec 23, 2016 •

edited

Loading

Dietermartens commented Jan 30, 2017 •

edited

Loading

magnolia61 commented Jan 30, 2017 •

edited

Loading

Dietermartens commented Feb 2, 2017 •

edited

Loading

magnolia61 commented Feb 4, 2017 •

edited

Loading

magnolia61 commented Feb 5, 2017 •

edited

Loading

magnolia61 commented Feb 6, 2017 •

edited

Loading