Internally RTBC'd by @anybody.
Nice generic test succeeds for both 10.3 and 11!
The js test failure will be solved in a follow-up issue.
I think I found something. The fix will be introduced through 📌 Implement SDK base integration Active .
HA, no way. We actually run into 🐛 Drupal 7 to Drupal 11 migration runs forever Active through the tests now!
ERROR: Job failed: execution took longer than 1h0m0s seconds
@heddn, so it actually makes sense now, to merge 🐛 Drupal 7 to Drupal 11 migration runs forever Active and this issue!
Test failures are related to a regression caused through 🐛 "[warning] Drush command terminated abnormally" as soon as posthog_js is installed Active .
This fix caused a regression for Drupal 11. We should make separate releases for D10 and D11:
PHP Fatal error: Type of Drupal\posthog_js\Form\SettingsForm::$typedConfigManager must be Drupal\Core\Config\TypedConfigManagerInterface (as in class Drupal\Core\Form\ConfigFormBase) in /var/www/html/web/modules/custom/posthog/modules/posthog_js/src/Form/SettingsForm.php on line 0
This should be it. Let's wait for entity_embed to get official D11 compatibility.
RTBC, works as expected!
Confirming RTBC and fixed typo
🐛 Drupal 7 to Drupal 11 migration runs forever Active isn't finished yet anyway and the current MR there, doesn't solve that issue as explained in the comments.
Yea no idea. I haven't decorated a symfony service before, so I am unsure what I am doing wrong here.... https://symfony.com/doc/current/service_container/service_decoration.html is not very helpful to be honest.
The current implementation should be correct, as we autowire the class_resolver as the constructor argument, but I still get the following error:
[error] ArgumentCountError: Too few arguments to function Drupal\layout_builder_st\DependencyInjection\DecoratedClassResolver::__construct(), 0 passed in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 and exactly 1
Even if I do it the non autowire way, like described in the docs, I get the exact same error.
If I add: class_resolver: ~ I get an error, that the decorated class couldn't get found (which makes sense, as we delete it, but its in the docs for some reason).
@phenaproxima do you have experience with decorating symfony services? Could you help me finish this?
Already done through 📌 Finish and test posthog_js Active . Only issue is 🐛 PH cookie gets set again after manually removing both the ph cookie and the cookiesjsr cookie and reloading the page ( Active , but everything else works great!
Added to merge train.
Thx for the clarification. Merging!
LGTM!
Commented one question.
Great stuff @simonbaese! Thanks for the superfast reply / fix! 🎉
Alright. Adjusted accordingly. I removed the hard pipeline failure for phpcs and phpstan, but I can revert that change again, if you disagree and want them to make the pipeline fail.
Back to needs work, based on the GitLab comment.
@simonbaese, @Anybody and I require this module for Drupal 11, as we just finished a Drupal 7 to Drupal 11 migration, where this issue can happen as well.
So it is indeed still relevant!
Nice, thx!
LGTM! One tiny comment, after that RTBC. Have you tested the update hook?
LGTM!
Ok, to summarize this. The current MR has nothing to do with the problem and won't fix it.
I successfully migrated all the media to D11:
After applying "3494209-14.patch", I ran into 🐛 Migrations fail due to missing dependency when dependency has skipped rows by the source plugin Needs review , because with the patch applied, the dependencies seem to not get resolved correctly anymore. So I manually removed the failing dependencies. After that, a MigrateException was thrown in `/src/EventSubscriber/MediaMigrationSubscriber.php`, line 256.
I simply added a return statement above and everything worked as expected:
if (empty($final_source_field_name[0]['field_name'])) {
return;
throw new MigrateException(
sprintf(
"Cannot identify the the media entity's source field name"
)
);
}
This is quite dirty, but everything seems to got migrated just fine! Of course we should find the real cause of this endeavour.
Just ran into this once again. After trying to migrate a site using media_migration enabled and a dirty workaround to get it to work with D11 ( 🐛 Drupal 7 to Drupal 11 migration runs forever Active , #14), I tried the latest 3 patches provided here, but nothing seemed to work.
I ended up simply manually removing the failing dependencies from the migration ymls. Luckily, they still migrated in the correct order, and the files migrated to media as expected. I think this is how I fixed the issue last time I ran into this.
I hope this might help someone.
Just a few phpcs fixes.
Dirty core patch for the time being.
@Anybody and I will have a deeper look tomorrow.
📌 Optimize SQL queries RTBC doesn't solve anything unfortunately.
Ok for some reason, the added array_map changes from https://git.drupalcode.org/project/drupal/-/merge_requests/1797/diffs?fi... in core migrate results in this issue. If we revert getMigrationDependencies() to how it was in D9: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/migr... drush migrate-import --group=my_migration_group --continue-on-failure won't be stuck in an endless loop.
I have no idea, how this module affects that line of code. I already commented out all code inside MigratePluginAlterer and in the module file. But it is still stuck in that endless loop, unless I comment out this modules MediaMigrationSubscriber "onPrepareRow" method.
Bug is back on the table...
Setting back to major, as the module isn't d11 compatible yet anyway.
But this can already get reviewed.
Waiting for 📌 Automated Drupal 11 compatibility fixes for media_migration Needs review to get fixed.
grevil → changed the visibility of the branch 3494209-drupal-7-to-with-d11-compatibility to hidden.
We found the issue!
This is caused by compatibility code for a core issue:
// @todo remove when https://drupal.org/i/3164520 is fixed.
$process = [
[
'plugin' => 'media_migration_delta_sort',
'source' => $field_name,
],
];
https://drupal.org/i/3164520 was already merged in 9.x, so no idea, why it suddenly causes an infinite loop in 11.x, but nevertheless, this should be fixed.
We will take a deeper look soon.
Ok, the reason for the infinite loop resides somewhere inside onPrepareRow() in /src/EventSubscriber/MediaMigrationSubscriber.php. Both running drush migrate-import --group=my_migration_group --continue-on-failure and drush migrate-upgrade --legacy-db-key=migrate --configure-only led to the infinite loop.
We tried deleting all migration ymls that were either provided or dependent on media_migration with no avail. After running the migration with minimal migration ymls in config the infinite loop still occured. Once we commented out the "onPrepareRow()" method call in the "MediaMigrationSubscriber" the migration started / the migration was configured successfully.
Done. Please review!
Test modules should be hidden by default, but this is more verbose! LGTM!
grevil → created an issue.
Alright, all done!
We are using the Svelte implementation instead.
CI Pipeline is fixed for 2.x now. Last test failure is related to https://github.com/jfeltkamp/cookiesjsr/issues/32.
I think we should drop support for 1.2.x, once 2.x is stable. The ci pipeline failure is related to version constraints from our composer.json. I would rather not mess with the version requirements in 1.2.x, as that would include deprecating cookies_ga, which we already deprecated in 2.x.
The last test failure is related to an upstream GitHub bug, I will create a follow-up issue.
New release created: https://www.drupal.org/project/markup/releases/2.0.1 →
All done! Update hook executes, hope it also works as expected (invalidating libraries.yml cache).
Accepting / Denying ALL cookies sets it to "true" / "false" as expected. This is only the case, when setting it via the "Cookie Settings" dialog.
The cookie value for "functional" will be false.
grevil → created an issue.
grevil → created an issue.
COOKiES has higher priority here, but since COOKiES is mainly client side, we need to find a way on how to solve this when setting cookies via the server.
Alright, now time for review.
@Anybody would like a setting to enable the fallback tracking.
Update hook works great!
Now this can finally get reviewed!
Forgot the update hook.
Ok really all done now. Please review!
Let's also integrate 📌 Add fallback option to track the parameter from current request, if cookie is empty Active here.
Let's actually implement this in 📌 Add fallback option to track the parameter from current request, if cookie is empty Active .
Alright, tested it a bit and refactored the code, ready to review now!
Done. Please review!
https://www.drupal.org/project/formblock → is not D11 compatible.
This will need quite the ambitious update hook.
Fixed in parent issue.
Fixed in parent issue.
Fixed in parent issue
All done! Please review :)
grevil → created an issue.
As discussed internally. The reason was, that "Do not track" was enabled.
Done, please review!
Let's have both issues fixed here. Although we should give credit to @mukesh88 for fixing the D10 compat issue.
Let's merge this in 📌 Drupal 11 compatibility fixes Active .
We are currently in the midst of getting project ownership, as we are still actively using this module. See 📌 Offering to maintain Custom Tokens Active . Hopefully this can get resolved soon.
For some reason the cookie is empty inside the tests. This doesn't make sense and I tried to find a reason why, but couldn't.
Not even @anybody could help us here, so we will end it here. The module functionality works great on actual sites, but for some reason not inside tests. Setting this to "Needs work". If anybody wants to finish this, go for it!