🇮🇳India @kunalkursija

I have resolved most of the pipeline issues except the PerformanceTest that's failing. Below are the different messages that I have been getting:

Line 75: Failed asserting that 59 is identical to 61.
Line 78: Failed asserting that 1 is identical to 2.
Line 79: Failed asserting that 27 is identical to 29.
Line 83: Failed asserting that 90360 is less than 90000.

Question: I noticed that core/tests/Drupal/Tests/PerformanceTestTrait.php calculates these values, but I'm unclear whether these numbers are updated based on specific criteria or the incoming test data. Could someone provide clarification?

Looks like the MR has conflicts due to changes in Plugins, Hooks & Test files. I will have to look into this and update the MR accordingly.

I have been working on this issue and have so far completed rendering the edit button and adding partial styles. Some more styling work is pending and then will be raising the MR for this.

Changing the version to 11.x-dev so that the Issue fork gets created from 11.x branch.

Getting started on this one locally.
Note: #3484564 is the dependency and this issue's MR can only be raised once the parent is done.

Have created below two issues to begin with where below will be implemented:

• Page Context Information: https://www.drupal.org/project/experience_builder/issues/3489107 📌 Create back link in XB Active
• Back Link: https://www.drupal.org/project/experience_builder/issues/3489107 📌 Create back link in XB Active

kunalkursija → created an issue.

kunalkursija → created an issue.

kunalkursija → created an issue.

Tried out the MR, This seems to be a solid way of defining the top bar elements. Thanks @plopesc!

I tried applying the patch today to see what functionality is being added. Unfortunately, The patch is failing to apply.
Navigation.module seems to be having conflicts.

@wim leers - The fatal error did not occur after applying the patch.

Testing Steps Performed:

• Took fresh clone of the XB module
• Applied the patch
• Installed XB.
• Installed Navigation
• Installed Navigation Top Bar

The patch looks good. Thanks @wim leers for the quick fix :)

@wim leers - I will test it today & share how it goes.

@cilefen - The error does not occur when the experience_builder module is uninstalled. Here is the entire error trace:

TypeError: Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences(): Argument #1 ($schema) must be of type array, string given in Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences() (line 50 of modules/custom/experience_builder/src/PropShape/PropShape.php).
array_map() (Line: 62)
Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences() (Line: 37)
Drupal\experience_builder\PropShape\PropShape->__construct() (Line: 41)
Drupal\experience_builder\PropShape\PropShape::normalize() (Line: 102)
Drupal\experience_builder\PropShape\PropShape::getComponentPropsForMetadata() (Line: 167)
Drupal\experience_builder\Plugin\ComponentPluginManager->propHasStorablePropShape() (Line: 156)
Drupal\experience_builder\Plugin\ComponentPluginManager->componentMeetsRequirements() (Line: 97)
Drupal\experience_builder\Plugin\ComponentPluginManager->setCachedDefinitions() (Line: 214)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 573)
experience_builder_modules_installed()
call_user_func_array() (Line: 416)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 395)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 415)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 381)
Drupal\Core\Extension\ModuleInstaller->install() (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install() (Line: 175)
Drupal\system\Form\ModulesListConfirmForm->submitForm()
call_user_func_array() (Line: 105)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 43)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 589)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Sorry for creating the issue here, Have created it in core - https://www.drupal.org/project/drupal/issues/3485820 🐛 Fatal error on installing the Navigation module Active .

kunalkursija → created an issue.

kunalkursija → created an issue.

kunalkursija → created an issue.

Wow, Great Find. That was quick 🎉

I am getting this error when enabling a new custom module on Drupal 9.5.10. The site is an old Drupal 8 site that has been upgraded to Drupal 9 a year back & it's a minimal Drupal profile. The steps that I performed were:

• Created a new custom module directory & the info yml file.
• Added custom migration yml in config/install directory. (Note: I don't have any other config files in config/install.)
• In CLI, I did drush en - y custom_module_name and got the notice & warning saying No configuration objects have been updated..
• Despite the notice & warning, The module gets enabled.

Even after applying the patches, The issue remains.

Patch #67 on stage_file_proxy 8.x-1.1 worked for me. However, The application that I am working on serves the private files from the overridden path(not system/files). Hence I had to save the patch locally and make below changes:

• The private files directory in my application is configured via settings.php in $settings['file_private_path'], So I updated the FetchManager.php file's code $file_dir = $this->fetchInfoService->getLocalSchemePath($fetchInfo->getScheme()); to $file_dir = \Drupal\Core\Site\Settings::get('file_private_path');. This ensures that stage_file_proxy saves the private files at the location from which they are read/served.
• The functions getUrlBasePath() & getFetchInfo() of SfpPrivateStream.php class has hardcoded the paths system/files & system/files/styles respectively. However, In my case, the files were being served from different paths and hence I updated it to suit my need.

The above changes made the patch #67 work for me.

I faced this today for doing paragraph_items to block_content migration, From Drupal 7 to Drupal 9. In my case, The block_content(of XYZ type) in D9 is translatable and paragraph_items in D7 were not translatable, But the nodes to which they are attached are translatable in D7.

I had to migrate all the revisions of the paragraphs[Not going into the details of work around paragraph's item-id/revision-id and node's nid/tnid to create revisions/translations of block_content].

When I ran the migration I faced a problem where the 'revisions' tab of the source translation showed more revisions than the actual count.

After looking into the tables, I sensed something was wrong with the 'revision_translation_affected' flag in tha DB table block_content_field_revision. And, Then I came across this issue and #6 by @firewaller. I used that solution by overriding the block_content entity's storage handler and it solved the problem and revisions tab started showing correct data.

Added the incorrect patch. Adding the new one.

Adding Patch.

I have tested the patch and the patternkit_block:BLOCK-ID cache tags are now getting invalidated only when a new node revision is created. This is how Drupal core is operating as well with custom-blocks. Things are looking good.

+1 on getting this merged in.