🇸🇮Slovenia @alecsmrekar

alecsmrekar → created an issue.

alecsmrekar → created an issue.

but the real issue here is that Drupal\group\Plugin\Group\RelationHandlerDefault::getRelationshipLabel() doesn't account for the situation when NULL is actually returned

In my view getRelationshipLabel is not wrong, it's respecting the return type of the GroupRelationship::getEntity method. Why check if something is NULL if the called function says it'll never be NULL. The called function GroupRelationship::getEntity is at fault here.

Adding this check would prevent the issue I reported in the issue description, but I think we should avoid tolerating wrong types, since types are very good guardrails.

alecsmrekar → created an issue.

alecsmrekar → made their first commit to this issue’s fork.

Maybe https://www.drupal.org/project/group_content_menu_bundles → can solve your problems

amateescu → credited alecsmrekar → .

alecsmrekar → created an issue.

Most entity types rely on an "update" operation instead of the "edit" operation. Paragraphs will check the "update" operation on it's parent entity. If the parent entity is a block, we'll need to convert "update" to "edit".

Here's a proposal for changing getBundlePermission:

  public static function getBundlePermission(string $block_bundle, string $operation): string {
    if ($operation === 'create') {
      return 'create ' . $block_bundle . ' block content';
    }
    elseif ($operation === 'update') {
      $operation = 'edit';
    }
    return $operation . ' any ' . $block_bundle . ' block content';
  }

Perfect, thanks! I didn't apply your suggestion as-is, because $this->requestStack->getMainRequest(); can also return NULL, so I took that into account.

alecsmrekar → changed the visibility of the branch 3420768-baseurl-used-in to hidden.

I ran the failing tests locally on 10.2.x with this diff applied and they are passing just fine.

There is a test failure, but I can't reproduce it locally. And I am not sure if it's indeed related to the changes from the PR

    Testing Drupal\Tests\language\Functional\LanguageUILanguageNegotiationTest
    ..E..                                                               5 / 5
    (100%)
    
    Time: 00:34.850, Memory: 4.00 MB
    
    There was 1 error:
    
    1)
    Drupal\Tests\language\Functional\LanguageUILanguageNegotiationTest::testLanguageDomain
    Behat\Mink\Exception\ElementNotFoundException: Button with
    id|name|label|value "Save configuration" not found.

alecsmrekar → created an issue.

I opened this PR with some initial work done on the JS side, it basically just avoids splitting the string if the form element has the data-autocomplete-single attribute.

alecsmrekar → made their first commit to this issue’s fork.

Rerolling the patch for D10.1 (without tests)

Updating the patch to read from the module/theme list service, instead of reading from cache directly. I also incorporated feedback from Stefanos.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

Thanks, committed to 1.0.x branch

I'm not sure how that's going to be implemented, but I assume that we might need to do some kind of settings merge: from the library sections storage itself and from the the entity view display.

Tested, works great!

Attaching patch and interdiff

Here's a small adjustment to #60 to allows admins to see the broken blocks, instead of suppressing the error "This block is broken or missing..."

Fix for patch not applying

We could also add a uuid regex to the routing file, which would prevent accessing the route with unexpected arguments.

The attached patch prevent the error from being thrown.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

I tried to run tests on the main branch, and I get the same failures locally, so I assume that the errors are not a consequence of the changes in the PR.

alecsmrekar → created an issue.

This is caused by the redirect module. The patch in here should fix it: https://www.drupal.org/project/redirect/issues/3314032 →

Opened MR 86 that's based on the 3.x branch.

alecsmrekar → made their first commit to this issue’s fork.

Opened a PR.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

Posted a PR.

alecsmrekar → created an issue.

alecsmrekar → created an issue.

..at least that Taxonomy Machine Name is enabled if the field name is machine_name.

I didn't do this explicitly, because this check would prevent you from using the field ID machine_name if you don't have the Taxonomy Machine Name module installed.

Opened a PR.

alecsmrekar → made their first commit to this issue’s fork.

Here's an alternative patch that does the same, but can be way faster. The patch in #2 works fine, but it require quite a bit of processing power to run all the Url:: calls.

So this code does the same, but it allows you to specify $settings['facets_short_pretty_paths_search_page_route'] = 'your_search_route'; which speeds up the facet rendering, especially if you have a lot of terms rendered on the page.

alecsmrekar → created an issue.