🇺🇸United States @daddison

As of right now this is still needed to remove smart dates as well from what I've seen.

I also can confirm this.

Hi maintainers! Please release a version for Drupal 11.

I second the "cordial community request" for a tagged release for Drupal ^10.3 and ^11.

Somebody please correct me if I'm wrong - My testing of this module with/alongside the core functionality in >10.2 has led me to believe that the core functionality only works when the cardinality of a multiple value field is unlimited (-1).

In the screenshot below, the "Related stories" field is unlimited and shows both this module's "x" removal widget and the core "Remove" button. The "Related events" field is limited to three values and shows only this module's "x" removal widget. Confusing!

The comment history in #1038316-74: Allow for deletion of a single value of a multiple value field → seems to indicate this is a feature not a bug. In my use case, fields with limited and >1 values need a remove option as well.

Anyway, I think this module still has utility with >10.2 and that should be stated on the module info page.

I think the `layout_builder_restrictions_by_region` module needs to be enabled to make use of this UI improvement, because a likely use case would be to restrict certain block types and block instances from being placed in the sidebar region of a two-column layout section.

Steps to test

1. Enable the the `layout_builder_restrictions_by_region` module
2. Per step 1 of the documentation → , re-select the layouts on which to configure restrictions.
3. In the configuration for each of those layouts (e.g. "Blocks available for the Two Column layout), toggle the radio button to "Apply block restrictions on a region-by-region basis"
4. Select the "Manage allowed blocks" button to open the configuration modal
5. Choose the block types, reusable blocks, inline blocks or plug-in blocks to allow or restrict in the layout regions

Hi maintainers. Thanks for this useful module. The update bot patch contains trivial changes for Drupal 11. When will you release a new stable version with support for Drupal 11?

daddison → created an issue.

I applied the patch on a site running 10.3 and checked the module's Drupal 11 compatibility using upgrade status module (static analysis). Functionally, the module works the same.

Hi maintainers - When will you make a Drupal 11 release of this module?

I have confirmed that this module is upgrade-ready by functionally testing it with Drupal 10.3 and Drupal 11. I also have performed static analysis of the module code with the upgrade_status module and it passed.

daddison → created an issue.

I applied the patch on a site running 10.3 and checked the module's Drupal 11 compatibility using upgrade status module (static analysis). Functionally, the module works the same.

@poker10 Do you have permission to cut a release for the 2.x branch? Seems the community has tested this and feels comfortable with this.

daddison → created an issue.

I rerolled the patch against the 3.x branch.

daddison → created an issue.

daddison → created an issue.

daddison → created an issue.

daddison → created an issue.

daddison → created an issue.

Proposed resolution

daddison → created an issue.

Hi @michaellander. Can you clarify the test scenario for this improvement? Does the layout_builder_restrictions_by_region submodule need to be enabled?

√ 1. Check for Drupal 11 code compatibility

One change required

1) web/modules/contrib/feed_block/src/EventSubscriber/FeedBlockCacheExpire.php:136

    ---------- begin diff ----------
@@ @@
    * @return array
    *   An array of event listener definitions.
    */
-  public static function getSubscribedEvents() {
+  public static function getSubscribedEvents(): array {
     $events[KernelEvents::RESPONSE][] = ['onRespond'];
     return $events;
   }
    ----------- end diff -----------

√ 2. Check for PHP 8.3 compatibility
√ 3. Check for jQuery 4 compatibility
√ 4. Update core version requirements to include Drupal 11
√ 5. Drop Drupal 8 and 9 support
√ 6. Unit tests are updated to work with Drupal 11 (PHPUnit 10)
√ 7. Automated tests pass D11 compatibility

D11 tests passed. Automated phpunit testing against Drupal 10 returned the following errors, due to this change.

1) Drupal\Tests\feed_block\FunctionalJavascript\RssTypesTest::testRss
Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for block_content.type.feed_block with the following errors: block_content.type.feed_block:revision variable type is boolean but applied schema class is Drupal\Core\TypedData\Plugin\DataType\IntegerData

2) Drupal\Tests\feed_block\FunctionalJavascript\RssTypesTest::testYouTube
Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for block_content.type.feed_block with the following errors: block_content.type.feed_block:revision variable type is boolean but applied schema class is Drupal\Core\TypedData\Plugin\DataType\IntegerData

I tested the D11-compatible code on a stock D10 site. Feed block revisions remain enabled even with boolean config value true, rather than 1.

√ 8. Change version numbering to use semantic versioning

√ 1. Check for Drupal 11 code compatibility
√ 2. Check for PHP 8.3 compatibility
√ 3. Check for jQuery 4 compatibility
√ 4. Update core version requirements to include Drupal 11
√ 5. Drop Drupal 8 and 9 support
6. Unit tests are updated to work with Drupal 11 (PHPUnit 10)
7. Automated tests pass D11 compatibility
√ 8. Change version numbering to use semantic versioning

√ 8. Change version numbering to use semantic versioning

√ 6. Unit tests are updated to work with Drupal 11 (PHPUnit 10)
√ 7. Automated tests pass D11 compatibility
√ 8. Change version numbering to use semantic versioning https://semver.org/

Hi @aperndo and @immaculatexavier,

You should be able to edit the MR in the gitlab interface to change the target branch to 2.x via the drop-down.

√ Unit tests are updated to work with Drupal 11 (PHPUnit 10)

√ Automated tests pass D11 compatibility

√ Unit tests are updated to work with Drupal 11 (PHPUnit 10)

√ Automated tests pass D11 compatibility

√ Check for Drupal 11 code compatibility

docker@cli:/var/www/web/modules/contrib/updated$ drupal-check -d ./
 6/6 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%


 [OK] No errors                                                                                                         

Thanks for using drupal-check!

√ Check for PHP 8.3 compatibility

php-compat ./
......

Time: 1.59 secs; Memory: 12MB

√ Check for jQuery 4 compatibility

Module does not use jQuery

√ Update core version requirements to include Drupal 11

√ Drop Drupal 8 and 9 support

√ Check for Drupal 11 code compatibility

docker@cli:/var/www/web/modules/contrib/iframe_title_filter$ drupal-check -d ./
 3/3 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%


 [OK] No errors                                                                                                         

Thanks for using drupal-check!

√ Check for PHP 8.3 compatibility

php-compat ./
...

Time: 194ms; Memory: 12MB

√ Check for jQuery 4 compatibility

Module does not use jQuery

√ Update core version requirements to include Drupal 11

√ Drop Drupal 8 and 9 support

Patch reviewed.

I applied the patch at #74 to the 8.x-1.x branch.

The module no longer presents the "unhelpful validation warning to consider using a URL alias instead" when adding a redirect from an internal path to an external URL.

The patch removes the unnecessary use statements, as indicated in the second point. 👍🏻

I confirm that the updated steps in the issue description reproduce the error.

daddison → created an issue.

The patch applies to 10.2.2 and restores the proper styling.

I'm using the 3.0.0-beta3 version of the module and have encountered the same issue with titles not imported from a RIS file. I have tried with a RIS file I generated and with the sample file provided by @camilocodes in the original issue.

daddison → created an issue.

daddison → created an issue.

I might have been unclear on the steps to reproduce. I enabled layout builder and layout builder restrictions for basic page on vanilla Drupal 10.1.5. I added one reusable and one inline Basic block to a node. Then I created a custom block type and added one reusable and one inline instance of the custom block to the node. I could not reproduce the error.

The issue summary still seems solid to me.

@johnv Yes, I did test with 🐛 Fix field cache for anonymous users by disabling caching in Status formatter Fixed implemented.

My use case is a university dining website with open/closing times on various locations. They still show up as open for anonymous users after they close, and vice-versa.

For sites that have page-level caching and, especially for sites that also use edge-caching via a reverse proxy such as CloudFlare or Fastly, the proposal to disable caching for anonymous users is not viable.

We need a different solution because we have to use caching.

I've also followed the "Steps to reproduce" and I also can't reproduce the bug.

I re-rolled the patch against 8.x-1.11.

Great work! I also test on a clean install of the umami profile.

Why are content blocks available as a linkable entity? Blocks do not have url paths.

When I link to a content block in the wysiwyg, the rendered output points to the admin configure form for the block. I think this behavior is of limited utility, and potentially confusing for many users.

I think content blocks should be removed from the available entity types that can be linked.

I re-rolled the patch against drupal/drupal, rather than drupal/core. Before and after screenshots attached.

Patch removes extraneous styling for inline block create button in stable9 theme.

daddison → created an issue.

daddison → created an issue.