That was already set as well but didn't seem to help - public and private are nested deeper under the symlink at /mnt/gfs/{$_ENV['AH_SITE_GROUP']}.{$_ENV['AH_SITE_ENVIRONMENT']} on the server as well, so I don't know why it would act differently
I also have this issue on site on an Acquia production server - I think the problem here is due to how the WebformExporter writes the file to tmp and how a load balanced server handles that during a batch...
Some findings that helped narrow the issue down and provide the direction for a fix:
- From a webform with many results (27k+), exports limited to created date of last 10 days.
- First export, automatically downloaded by the browser: 835 results (matches # shown in the batch)
- First export, clicked the file download link in the Drupal message: 0 byte file. The file existed and didn't 404, but was empty
- Second export, automatically downloaded by the browser: 335 results no headers (browser briefly showed an updated message in the batch at "Exported 500 results")
- Second export, clicked the file download link: 500 results, with a header!
Combining the second exports into one file and diffing the result with the first auto download resulted in a file with no differences from the first download. So the 500 results in the file in the message were the first part of the file.
So obviously the second batch completed, just into two similarly-named temp files. I assume this is a weird quirk of a load-balanced server and how the temp directory on Acquia or Pantheon is handled (on Acquia it is /tmp and not a shared symlinked file server like public or private) This might also explain why the local export works 100% of the time. This is also likely why the drush export suggested in #21 works.
I changed the temporary directory at admin/structure/webform/config/exporters to a sub-directory of private:// and the export works every time now. The help description on the directory does say that it should be persistent directory, so that may confirm why /tmp had problems on Acquia. This is not perfect since the resulting file export will not be automatically removed, but since createExport() in FileHandleTraitWebformExporter.php calls fopen() with the 'w' mode, it will only create one export file and overwrite it every time.
Committed and added a release for that as well
Thanks for the find! That would definitely throw an error in D10, so I have added your patch and made a new release
The notification data is on the notification entity which is the parent entity of the display paragraph - so you should be able to call -> getParentEntity() on the paragraph and then load fields from there. You could probably do that in a preprocess for the paragraphs and add them into the variables for the template
Added patch with additional catches for the other two preg_replace calls - putting them into double quotes is a shorter fix, but it's less readable and can be the cause of weird bugs if the data type changes.
Talking to our team, it sounds like dev have done this before by adding the library to the DMB block, which is not an ideal solution. I think because of how this is loaded attached libraries in the template are likely not working, so this is definitely a bug
That's an excellent point, I'm making this a bug right now. Thank you!
Are there any errors in any logs or console? It looks like it is displaying the notification entity, or at least that it is adding something in there, so I would check the default display of the Notification to make sure you are displaying the paragraphs.
The readme will be changing as D10 updates are merged in, it has already been changed to a markup file. The issue was to change the format, which has already been done. There is no need to merge the code changes as they are outdated.
Please do not re-open this issue.
Sorry, there are a lot of changes upstream for Drupal 10 and this issue will remain closed.
There seemed to be a regression in the regex in patch #72, I have updated it so it applies for 9.5.x and does not break