Simply reporting that patch https://www.drupal.org/files/issues/2023-10-01/2998114-88.patch → applied successfully on 2.0.11
- Installing drupal/block_class (2.0.11): Extracting archive
- Applying patches for drupal/block_class
https://www.drupal.org/files/issues/2023-10-01/2998114-88.patch (https://www.drupal.org/project/block_class/issues/2998114 Integration with Drupal core's new Layout Builder)
Thanks for the quick reply! (In my original comment, I began typing out a suggestion but it ended up as a question.)
The suggested improvement is to add a recommendation that module maintainers flag it in their release notes when a release has configuration schema changes. (This alerts site maintainers that besides updating the module, they'll likely have to re-export its configuration settings into their version control.)
I'm happy to take a stab at editing the page myself, but I don't want to make rogue changes.
I can't think of or find a better place, so I'm posing this question here. Specifically, what is the best way to include or flag in release notes that config schema changes have been made and that anyone updating to the latest module version may need to update their site's associated configuration and re-export its yml file(s)?
The main use case I have in mind is for workflows with merge requests created by automated composer updates. (e.g. Using Violinist or Dependabot) As a reviewer for these automatically created merge requests, I skim the release notes, check in the testing environment that nothing is broken, merge the update and that's that. However, some updates may include configuration changes and it's not obvious that they do. I'm imagining in the list of release notes something like "This release includes configuration changes, make sure to re-export your example.settings.yml."
I wonder, is there a way to automatically identify if an update includes new configuration settings?
Update Drupal 7 end of life date to January 5th, 2025 and remark that the date is final, linking to https://www.drupal.org/about/drupal-7/end-of-life →
Changing it's to its. (it's = "it is", its = "belonging to it")
The patch from #29, https://www.drupal.org/files/issues/2023-03-21/protected_pages-2239433-d... → , successfully applied to the 8.x-1.6 version of protected_pages.
Here is a screenshot of the Validate per section checkbox in action.
My testing has been successful, in that I could access multiple password-protected pages by entering a password once. (Without the patch, the module expects you to enter a password for each protected page you visit.)