Is this possibly a method you added via a patch?
That idea hadn't even occurred to me! You are spot on - it's a patch I've been using for years and gets applied via Composer without me even thinking about it any more. And today when I debug things - without changing anything since yesterday - I no longer need the extra exists() method anyway, which is really confusing. file_exists() is now using the S3fsStream::url_stat() method, as you would expect.
Everything seems to be hunky dory after all. Sorry for the false alarm!
paulbeaney → created an issue.
I have made what I think is some good progress on this - at least, it works, and it doesn't seem to interfere with drush commands other than the two this module is targetting. I have implemented 2 annotated hooks in MigrateBoostCommands which run before migrate:import and migrate:rollback (one callback to target each command) and simply call MigrateBoost::enable().
I have created a fork and updated the file on GitHub, but this is my first foray into non-patch contribution, so if I need to do anything else to make it visible or otherwise complete the process, please let me know!
Thanks for getting back to me and sorry for omitting that rather important bit of info! I am using drush 12.5.3.0.
I'm not familiar with the inner workings of drush so I haven't been able to dig too deep yet, but initial debugging seems to indicate that functions such as initCommand(), boosterEnable() and bootDrush() only get called when running either of the Migrate Boost module's own commands (i.e. enable or reset). The rest of the time, the first thing that gets called seems to be MigrateBoost::alter().
I'll keep digging and feedback anything I find and if you have any ideas of where to look, I am all ears!
paulbeaney → created an issue.
Just got hit by this after updating to PHP 8.3. The MR works great, thanks.
In case it helps anyone else, the attached patch got me out of this hole while things get sorted. Basically it just puts the annotations back into the core request_path plugin, allowing the attributes to carry on working whilst Rules can do its thing.
Just managed to get all this up and running with a bit of tweaking for my specific scenario, but there does seem to be one basic problem: this migration re-uses the Promotion Usage destination plugin, but said plugin sets the coupon_id to zero in the import() function. I ended up just tweaking the function to this so that the Coupon Usage migration can supply the value for coupon_id:
public function import(Row $row, array $old_destination_id_values = []) {
$success = FALSE;
$values = ['usage_id' => 0] + $row->getDestination();
...Just tried applying this patch but it chokes on 2 parts relating to commerce_product_bundle.install - there are line numbers which simply don't exist in what I am seeing here, and reference $config_manager which doesn't appear anywhere in the project that I can find. Have I missed a trick? (Did a composer remove/require to ensure I had the latest version).
Assuming I haven't, attached is a patch without the 2 offending chunks, and also including the automated patch from #3411548 to make a complete D10 update patch.
Monitored room 3.5 & 3.6
Been looking at this at Contrib Day after Lille Drupalcon but haven't been able to make any progress as it looks like the MR hasn't been rebased, and when manually rebased to drupal-1671190/11.x ended up with this error on /core/install.php.
Fatal error: Cannot redeclare format_size() (previously declared in /var/www/html/repos/drupal/core/includes/common.inc:141) in /var/www/html/core/includes/common.inc on line 143
Looks like a manual rebase of this branch is required to bring everything up to date?
Ditto!
Ditto :)
paulbeaney → created an issue.
Apologies, just seen this is fixed in 4.2.12. My composer wasn't updating properly - had to remove and install from scratch.
paulbeaney → created an issue.
I can confirm that contextual filters seems to be the problem. I have a partially-working way round it for the my use-case - displaying an add-to-cart block for a Commerce Product related to the content being viewed.
Two steps are required:
- In the block Ajax configuration, set it to use GET rather than POST.
- In the contextual filter configuration of the view, for the section When the filter value is not available, select Query parameter as the type, and enter nid for Query parameter.
With these 2 changes, the block shows - albeit with the spinning ajax icon still visible below the block - but only on the first page load after drush cr. Subsequent page loads (which are of course cached by Drupal) result in only the block title and product price showing - the add-to-cart button does not appear, and again the spinning ajax icon remains visible.
This button problem might be specific to Commerce as I can see a <drupal-render-placeholder callback="commerce_product.lazy_builders:addToCartForm"> tag in the returned JSON.