I wonder if 🐛 Fix backwards-incompatible Json data_parser API change included in 6.0.3. Needs work already fixed this issue. I've pushed some test coverage, but it doesn't trigger any errors. This might be a test only change to make sure these issues don't surface again. But I think the real problem is fixed elsewhere.
Is there any chance to add a quick test so this can't happen again?
Needs to be in an MR. Patches don't work with the workflow that triggers tests.
Also, a more fundamental question. How is this different than config_entity that is part of drupal core itself?
If that isn't the case, we can re-open with steps to reproduce the issue on the current HEAD. Thanks for the confirmation this doesn't seem to be an issue.
Is there any chance of moving that patch into an MR and adding tests?
Drupal 10.1 is no longer supported. I think we can safely close this now?
I don't think this is still a valid issue any more. The code seems to pass all of the code standards test provided by the CI engine.
I'm relieved. Thank you for your blog post too. It will help others who are also facing this situation. Plus its a great walk through how to upgrade from annotations to attributes. I also found that using PHP Rector was very useful in this space too.
I've added https://www.drupal.org/node/3569238 →
We should add a test scenario to existing tests to test this new permissions model.
There was a quick followup in 🐛 Syntax error in DataParserPluginManager Active . Its landed for a while. I just noticed I hadn't tagged a new release though, so I've release it now with https://www.drupal.org/project/migrate_plus/releases/6.0.10 →
If you can still reproduce the issue after updating, let's open a new issue and link it back here so we can further investigate.
I read in https://www.undpaul.de/en/blog/2026/01/20/converting-php-class-annotatio... this is very disruptive and:
Old annotation-based plugins will not be discovered and will cause migration failures.
Is this truly the case? I thought that with listing Drupal 10.5 as minimum drupal core version and core's ability to support both annotation and attributes at the same time, that other custom or contrib modules could still maintain annotations without any more effort. Can anyone report to the contrary with steps to reproduce?
This makes me think we might have an issue if someone has the wrong permissions assigned. Any suggestions how to make this work in a BC manner?
Is there any way to get a test added for this? What is moderation dashboard that a test block or controller couldn't add so we can increase the scenarios tested for this module?
But the patch needs to be rolled into an MR to ever stand a hope of getting merged. We do that so it has tests run and is reviewable. Leaving at NW for this next task.
There s a 2.0 stable release as of today. Is that an option now? Alternatively, we could backport this.
We should add some doxygen about how to use this new feature. Otherwise, this is pretty much set to go.
Patch needs conversion into an MR. Also, is this an issue on 2.x? If it isn't then we can fix 1.x, but let's confirm it is or isn't there first.
There's 2 competing MRs and no tests in either. Lets decide on which MR we want to use, close the other and ideally add some tests.
Drupal 11 release tagged.
https://www.drupal.org/project/layout_builder_st/releases/2.0.0 →
This is now resolved. With passing tests, we can now tag a release.
It seems to be some type of race condition. If I add a few sleeps into things, then it starts to collect. But it seems to collect a lot of noise from flood, session and previous user login that wasn't there previously. I'm not sure what the difference between functional and javascript is, but there seems to be something.
diff --git a/core/modules/system/tests/modules/performance_test/src/PerformanceDataCollector.php b/core/modules/system/tests/modules/performance_test/src/PerformanceDataCollector.php
index d026b756d29..92adf9059c5 100644
--- a/core/modules/system/tests/modules/performance_test/src/PerformanceDataCollector.php
+++ b/core/modules/system/tests/modules/performance_test/src/PerformanceDataCollector.php
@@ -81,6 +81,7 @@ public function destruct(): void {
if (!$lock->acquire('performance_test')) {
$lock->wait('performance_test', 10);
}
+ sleep(2);
$collection = \Drupal::keyValue('performance_test');
$existing_data = $collection->get('performance_test_data') ?? [
'database_events' => [],
diff --git a/core/tests/Drupal/Tests/PerformanceTestTrait.php b/core/tests/Drupal/Tests/PerformanceTestTrait.php
index 02872b84f48..04cb3ecce65 100644
--- a/core/tests/Drupal/Tests/PerformanceTestTrait.php
+++ b/core/tests/Drupal/Tests/PerformanceTestTrait.php
@@ -112,6 +112,7 @@ public function collectPerformanceData(callable $callable, ?string $service_name
$session = $this->getSession();
$collection->deleteAll();
+ sleep(15);
$performance_data = new PerformanceData();
Drupal 11 is now working, but Drupal 10 is now failing. Getting closer.
I'm confused. I've converted the JSON::API test over but the db collector isn't getting triggered to collect queries.
Can we roll this into an MR so tests can execute? Ideally we add tests.
I think this is long out of date. If that isn't the case, feel free to re-open and provide an updated direction.
I think this is long out of date. If that isn't the case, feel free to re-open and provide an updated direction.
Marking as duplicate of one or both of the mentioned tickets in #10. If this is inaccurate, feel free to re-open and document what else should be done.
There's not much we can do here. Except point to a blog post or a wiki page showing how to do this.
The patch should be rolled into an MR. Ideally we add test coverage.
The patch should be rolled into an MR. Ideally we add test coverage.
Those issues should be resolved fairly quickly, so I'm not going to move forward here unless those stall out for some reason. If they do stall, we can reopen and consider doing these changes.
The only worry I have with CI test failures is the cspell on dataparser. If we can add that to the allow list, then this looks good to me. The default previous version of drupal core is about to change any day now so I'm not too worried about getting that green.
Can we covert that patch into an MR so we can see how tests fair? And ideally add a test while working on this?
That makes sense. I guess if we wanted to we could add a test module with the legacy annotation and test for that. But not its fixed, it isn't likely to happen again.
need to add a .cspell-project-words.txt with the names of the module maintainers to avoid cspell errors.
If this is all about tracking a new release, updating the title.
I agree, this is a duplicate of https://www.drupal.org/project/layout_builder_st/issues/3497945 📌 Make coding standards fixes Active
https://www.drupal.org/project/layout_builder_st/issues/3497945 📌 Make coding standards fixes Active seems to have resolved this indeed.
I assume that once this gets merged, we'll add the link target to https://www.drupal.org/node/3223395#s-migrate-drupal? Ah, just reviewed the IS. It is in there as next steps.
I don't see a CR though. Do we still need to add that? Otherwise, +1 on RTBC.
Can we add some screenshots showing before/after the problem and its fix?