🇳🇿New Zealand @kent@passingphase.nz

I had this error and tried everything in the thread.  Then I ran drush cc --debug and got the result:

sh: mysql: command not found

The solution was to add:

export PATH="/usr/local/opt/mysql@5.7/bin:$PATH"

to .bash_profile

Interestingly Drupal 9 sites on the same server were unaffected, but of course, were using a different version of Drush.

Thanks, Anybody.  Where the Migrate file to media module has failed, this one works a charm.

lexsoft, was your entire command:

drush migrate:import d7_node:product

?

How does it know where to look? I tried that and nothing happened. My original command was:

drush migrate:upgrade --legacy-db-key=migrate --legacy-root=http://my-local-domain

Thanks!

Yes, the reason for the custom folder is that the module has its own git repo that is made available as a package from gitlab, therefore it is not to be altered within the current repo. Meanwhile all modules under custom folder belong to the current repo and should be altered as required within the current repo.

My apologies. Actually, my intention is to install in a custom folder and not the standard "drupal-custom-module", for which the solution I provided seems essential.

I was not able to get this working by any of the methods outlined. Instead I am using this library: https://github.com/oomphinc/composer-installers-extender and ensured that my type name is prefixed with 'drupal-'. No need for any fancy packages in repositories or anything. Just ensure that the type name used in the custom module/library is the same as the one you want to save to your custom directory:

e.g in the module

{
  "name": "myproject/mymodule",
  "type": "drupal-myproject-custom-module",
  ...
}

And in the root composer.json:

          "web/modules/myproject/{$name}": [
                "type:drupal-myproject-custom-module"
           ],

Hey rahul,

I haven't got much time for this at the moment. Would you like to become a maintainer of the project?

Attached is the patch we have been using to enable use of latest revision for access by ref.

Thanks, @John Pitcairn. I'll try running cron from crontab, and post this issue on a suitable module elsewhere.

Commerce license is an essential part of the recurring payment existence, in that these are subscriptions, for which is a license is assigned. If I have no luck I will try removing commerce license as a test.

The only other patch applied is to commerce, as follows: https://www.drupal.org/files/issues/2021-05-12/commerce-send_mail_after_... → , which involves sending an email when purchasing and registering at the same time.

I've been trying to get commerce_stripe going with recurring payments for a few weeks now while in Stripe test mode.
commerce_recurring 8.x-1.0-rc1
commerce_stripe 8.x-1.0-rc8
commerce_license 8.x-2.0-beta2

I've applied the patch at #72 and set my future usage to off session in the Stripe Review pane. I still get a fail on the first recurring attempt.

RuntimeException: Failed to start the session because headers have already been sent by "/vendor/symfony/http-foundation/Response.php" at line 1239. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 152 of /vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

This is different from the one I got prior to the patch, which was:

/html/core/modules/big_pipe/src/Render/BigPipe.php" at line 264. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)

Will keep testing and see what I come up with.

The event subscriber user_email_verification.verify appears to be now in core.