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 pathssystem/files&system/files/stylesrespectively. 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.