🇨🇦Canada @gordonio

I believe I am seeing the same issues as #12, but for the most part it's working fine. It was reproducible when I had more than two languages.

1. Enable more than 2 languages
2. Create a page in the original language
3. Translate to One of the other languages
4. Translate to the third language

What I was seeing was:

1. Original language is always okay
2. The block description of either of the translated ones would use the text of the previously translated item. For example, set the block translation in french. Then create a spanish version and save the block. The french block description would be the spanish one when viewing, but show the french text when editing.

It appears to be unrelated to this module and there is a thread for what I believe is the same issue here: https://www.drupal.org/project/drupal/issues/3240993 ✨ Let layout builder render inline block translations Needs work

Here's a version of the above patch without the database queries that is working for me.

I ran into this issue as well with 2.x but it looks like it is still there with 3.x as well. Mainly an issue with a large facet set where not all facets options are visible immediately.

Here's a re-roll to work with 2.x and 3.x.

I ran into the same issue as #31 with the opener_id error. The patch in #34 seems to be working fine for me and I haven't noticed any issues with filtering so far.

Core Version 10.2.6

I have run into this a few times with CI pipelines and it is a bit of an annoyance. I agree with sokru that we should handle it automatically if it doesn't exist. I can't see a downside to having it there, even if it is empty.

It looks like this only got partially added. The part with the explode to separate the countries doesn't appear to be there. Here's a patch re-roll with just the country explode if anyone needs it.

pameeela → credited gordonio → .

Patch #43 worked for me. Layout builder shows the correct entities in a non published state, and the published version displays the correct revisions.

I ran into this issue as well. It looks like it's because enable_social is set to false to begin with.

I have been able to reproduce this issue with the following:

1. Add a view to a global section of the site (Mine is an exposed form search block in the site header)
2. Go to a url that gives you a 404.

In the following, $route_name returns null and then fails the strpos.

  public function viewExposedFormBlocks() {
    // Avoid interfering with the admin forms.
    $route_name = \Drupal::routeMatch()->getRouteName();
    if (strpos($route_name, 'views_ui.') === 0) {
      return;
    }
    $this->view->initHandlers();

    if ($this->usesExposed() && $this->getOption('exposed_block')) {
      /** @var \Drupal\views\Plugin\views\exposed_form\ExposedFormPluginInterface $exposed_form */
      $exposed_form = $this->getPlugin('exposed_form');
      return $exposed_form->renderExposedForm(TRUE);
    }
  }

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

gordonio → created an issue.