I am converting D7 webforms for D9 and importing data (latest webform 6.1.x and Drupal 9.5.x, CiviCRM 5.63.1).

To do a basic test I created an import file with a single entry and used the UI to import, treating all warnings as errors to be sure. This was successful (thanks Jacob Rockowitz for the video on this Import Webform Submission)

The forms are linked to CiviCRM.

I have a fair few to import so switched to the command line to avoid any time out issues and I can also script this way. I ran into a strange problem where an identical import fails using the CLI.

Drush webform:import myform /my_path/my_file

If I swtich back to the UI all 100 were imported without issue? The submissions look OK in the UI and I checked a few at random against the current D7 system and they are fine. All I see in the dblog is a load of warnings about unserialize(), but that's it.

Here is what I am seeing when I try to use the CLI:

Command line output

Here is an example of one of the numerous deprecated function debug messages (I am using PHP 8.1 so that's probably it):

Deprecated function warning

Just in case, I have experimented with using --treat_warnings_as_errors and --skip_validation to no effect.

I can do it all via the UI, but would rather not! Any thoughts on this welcome.

2 Answers 2


The issue was, as Demerit rightly pointed out (thank you!) to do with Drush running as a user that did not have the privileges to create a submission for my particular webform. The form was not a simple one, involving several contacts, a case and an activity all with custom fields.

The solution, a total hack, was to elevate the Anonymous user by temporarily granting the following permissions:

CiviCRM: all CiviCRM permissions and ACLs
Administer and use CiviCRM bypassing any other permission or ACL checks and enabling the creation of displays and forms that allow others to bypass checks. This permission should be given out with care

Clearly this is a very dangerous thing to do and you should not leave this on a production system or one exposed to the open internet. The solution is to lock the site behind HTTP Auth and or put the site into Maintenance Mode to do your import, then immediately remove this permission when you have done your import.


If you are running drush as anonymous civi won't have a source_contact it can use. As noted in comments it seems with recent drush versions you can no longer set a user id, but all drush commands are equivalent to just calling some function in the code. For this one it looks like it's

\Drupal::service("webform.cli_service")->drush_webform_import($webform_id, $path_to_csv, [array of options]);

so you can use drush ev to first set a user, then call that function, e.g.

drush ev '\Drupal::service("account_switcher")->switchTo(new \Drupal\Core\Session\UserSession(["uid" => 1])); \Drupal::service("webform.cli_service")->drush_webform_import($webform_id, $path_to_csv, [array of options]);'

  • Thanks Demerit, I'm definitely running as anon. Tried your suggestion but I'm getting 'The "--uid" option does not exist' - running Drush version 10.6.2. I did not think you could run Drush with a user anymore? I know I've done it on D7 in the past (--user=[username]) , but rarely have had to use it.
    – ChumKui
    Jul 21, 2023 at 17:21
  • Oh that's weird. Ok will update answer.
    – Demerit
    Jul 21, 2023 at 18:22
  • HI Demerit - so close... So in summary it fails with 'The "entity-type" option does not exist'. Thanks for this as an admin/needs must developer, it is great to be introduced to the lower level of Drush and how it can be used. I ended up using the debugger, not a natural country for me. It fails at line 427 - $entity_type = $this->drush_get_option('entity-type'), but stepping in, ultimately fails on a Symphony getOption($name), where $name = entity-type. A bit low-level for me all this, but nearly there? I've learned a lot along the way. Many thanks again.
    – ChumKui
    Jul 24, 2023 at 10:07
  • Ok not sure. Maybe for some reason it needs --entity-type specified on the command line?
    – Demerit
    Jul 24, 2023 at 15:19
  • 1
    It is definately a permissions issue - if I allow anonymous users access to CiviCRM with elevated permissions, the import works. I have raised an issue for the webform module (drupal.org/project/webform/issues/3376837). Non dev users would definately not want ot start to create custom modules to do this sort of thing.
    – ChumKui
    Jul 25, 2023 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.