Export fails on PHP 7.3

Are you sure that is PHP 7.3? Seems likely some particular field or record is failing to export. If you create a simple form with lets say just a text field, and something something like Test123, does it export?

This module actually uses csv_serialization module to handle the serialization for the CSV, but without the actual data it is likely going to be hard to reproduce this issue. Also if you could turn on verbose error reporting (ie, add '$config['system.logging']['error_level'] = 'verbose';' to settings.php) and send the full report from admin/reports/dblog - essentially looking for the stack trace which is the list of functions / files that were called before that as that error points to an action taken by Drupal Core.

So I think next steps are:

1. Provide full error report
2. Try this out with a simple form to ensure it is actually related to particular results
3. If it is particular results, we can speak about getting some of the data (anonymized) to try to reproduce

Hmmm it doesn't seem to point at any code from Contact Storage Export. This module utilises CSV Serialization module to handle that (https://www.drupal.org/project/csv_serialization). Perhaps this issue should move there.

I have the same Problem,

Notice: unserialize(): Error at offset 53202 of 70123 bytes in Drupal\Core\Batch\BatchStorage->load() (line 71 of core/lib/Drupal/Core/Batch/BatchStorage.php).
Drupal\Core\Batch\BatchStorage->load('90') (Line: 75)
Drupal\Core\ProxyClass\Batch\BatchStorage->load('90') (Line: 43)
_batch_page(Object) (Line: 55)
Drupal\system\Controller\BatchController->batchPage(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Aucun traitement par lot actif.

Hi Nikral,

Thanks for your comment.

As per #2, I will need more details to be able to help you at all.

But as per #5 it is very likely that the issue is not with this module, but with the module that handles the serialisation (given the error message is Notice: unserialize(): Error at offset 53202 of 70123 bytes) which is csv_serialization.

Thanks,
Scott

scott_euser it is a problem with serialization, but not csv_serialization but serialization that is done while preparing a batch operation, which is in core. After we discovered this issue on our project we tested it on a fresh Drupal 8 install (8.8.2) using PHP 7.3 and we also encountered the problem described above.

There is already an issue for this: https://www.drupal.org/project/drupal/issues/3055287. After applying the latest patch in the issue (#20), exports started to work.

Thanks for digging into that! I am sure your find will come in handy for someone else in the future. Added as a related issue.

Hate to be that guy that reopens tickets, I've read https://www.drupal.org/project/drupal/issues/3055287 as explained in #8 its not a common scenario, there does not seem to be a clear consensus on the solution and more work is needed, so it might take a while for it to be fixed.

In our case the issue seems to be the Request object that triggers the issue, I suggest this patch that works around that, so we have the fix here now.

btw to reproduce its really easy, just try to export under php7.3 you will get error batch not found, and if you check the logs you will see the unserialize notice.

Thanks for your feedback. I am able to export on 7.3 on my local and export via automated tests are also passing on 7.3: https://www.drupal.org/node/2752613/qa so I do think we need more information about how to reproduce. I am guessing the solution in the related issue did not solve it for you then? How does removing the request object solve this?

Essentially the issue must be reproducible somehow, and if so, we can add a test that shows it is not working correctly with corresponding code to fix the issue.

adding test for issue, hoping this will fail...

Good, failed with Exception: Notice: unserialize(): Error at offset 38407 of 53502 bytes (https://www.drupal.org/pift-ci-job/1649697)

And this should now prove the fix, fingers crossed..

Hi @scott_euser,

in #13 I provided a patch which reproduces the issue, I used a browser test with form submission to trigger the error (as it is in the user interface).

in #15 I merged #10 with #13 to show that my original patch solves the issue.

Please review, let me know if you want anything changed.

Thanks.

Patch in #15 resolved the issue for us. Recently upgraded to PHP 7.3 and started seeing this.
Thanks all!

I just encountered this too using PHP 7.3 - it's definitely fixed by the patch in #15. One alternative to patching to use a different request class would be to only pass necessary data into the batch process instead of the entire form_state values.

I believe the issue is that the full values array includes references to classes and data types - the names of these classes and datatypes are sometimes serialized with NULL (ascii 00) characters surrounding an asterisk. I don't exactly know why, but as an example a batch without the patch had values like s:10:"<NUL>*<NUL>options" in my database. PHP's unserialize trimmed <NUL>*<NUL>options into *options and the byte count went from 10 to 8.

Refactoring this batch to pass a simple associative array with only the values needed for the process would also solve this issue.

We've tested the patch in #15 as well and can confirm that it resolves the issue.

Thanks for the patch - works for me as well! Thanks also for the suggestions Mojiferous - I'll keep the change simple for now to get it fixed and could consider some refactoring in the future to pass less to the batch.