🇳🇱Netherlands @Web-Beest

Thank you!

Works for me :-)
RTBC +1

Hi Sergei,
No, this was eventually not the problem. The main thing was the CORS issues.

Web-Beest → created an issue.

Post op Drupal.org m.b.t. component css die eerder wordt ingeladen dan basetheme css
https://www.drupal.org/project/drupal/issues/3374901 🐛 SDC Stylesheets are output in the wrong order (relating to normal libraries) Active

I've run into this issue as well. I've created a subtheme of Bootstrap5 and my problem is that my styling is loaded prior to the base styling, rendering my styling useless.

The problem resides in LibraryDiscoveryParser as eelkeblok already suggested. The stylesheets are loaded by the SDC module, which will always result it in them being placed in the CSS_AGGREGATE_DEFAULT group, higher up the chain then CSS_AGGREGATE_THEME.

I don't have a solution for this but I've came with this workaround for anyone who encountered this problem:

/**
 * Implements hook_library_info_alter().
 */
function theme_virtuel_library_info_alter(&$libraries, $extension) {
  if ($extension == 'sdc') {
    foreach ($libraries as $key => $library) {
      $libraryName = explode('--', $key);

      if (empty($libraryName[1])) {
        continue;
      }
      $library['dependencies'][] = $libraryName[0] . '/' . $libraryName[1];
      $libraries[$key] = $library;
    }
  }
}

/**
 * Implements hook_library_info_build().
 */
function theme_library_info_build() {
  /** @var \Drupal\Core\Asset\LibraryDiscoveryCollector $libraryDiscoveryCollector */
  $libraryDiscoveryCollector = \Drupal::service('library.discovery.collector');
  $theme = \Drupal::theme()->getActiveTheme();

  $libraries = [];

  // Duplicate SDC libraries as dependencies.
  $sdc = $libraryDiscoveryCollector->get('sdc');

  foreach ($sdc as $key => $library) {
    $libraryName = explode('--', $key);

    // Only add items that have a component.
    if (empty($libraryName[1])) {
      continue;
    }

    $cssFiles = [];
    foreach ($library['css'] as $cssKey => $cssDefinition) {
      $start = strpos($cssDefinition['data'], $theme->getName()) + strlen($theme->getName());
      $cssFiles[] = base_path() . $theme->getPath() . substr($cssDefinition['data'], $start);
    }

    // Remove asset from SDC, otherwhise it will be loaded twice.
    unset($library['css']);

    $sdc[$key] = $library;

    // Create library based on SDC definition.
    foreach ($cssFiles as $cssFile) {
      $libraries[$libraryName[1]]['css']['component'][$cssFile] = [];
    }
  }

  $libraryDiscoveryCollector->set('sdc', $sdc);

  return $libraries;
}

Update-bot patch is incomplete.

Crikey.. identation problem in schema.yml
Ignore #10

I've rerolled the patch for 8.x-3.x for those who want it :-)

So, in hindsight, the args is not the place where you want to do this. It would result (if it worked) in rendered HTML appearing in your controls-pane in Storybook.

I've combined Storybook with SDC and came up with the following solution. I define the arguments I want to use in the args so I can alter them in controls. If you don't need to alter them, just define them as variables in Twig.

In the component I've defined properties and slots. The slots are there so you can embed large blocks as content without it being a property of that component. So for instance a fieldset has a legend and 'children' (which can be anything). This is a place where you can embed a large piece of content.

Fieldset template

<fieldset>
  <legend>{{ legend_title }}</legend>
  {% block children %}
  {{ children }}
  {% endblock %}
</fieldset>

In my story I embed the component with a block:

    {% embed 'theme:fieldset' with {
      legend: 'Fieldset legend'
    }
    %}
      {% block children %}
        {{ include('theme:component') }}
      {% endblock %}
    {% endembed %}

This way you can reuse stories / components in other stories.

For us, the problem emerged after updating to core 10.2.3
We have several nodes with multiple aliases, but it couldn't find the correct alias when visiting a page on the old alias. It ended up in a redirect loop.

Node: /node/1
Current alias: /path-to-node
Old alias: /old-path-to-node
Redirect: /old-path-to-node -> /path-to-node
That caused the redirect loop.

The patch in #7 fixes it.

I've rerolled the patch against 8.x-1.9 for anyone who's interested.

+1: I was looking for the same thing :-)

Just another debug hint: check the console for errors. I've just encountered the same error with my environment that was working earlier. In my case it was a CORS error (development.services.yml was overwritten).

I've got mine working now. I've created a new, clean setup (using Lando) and now it works. The only difference with regards to project structure is that I have created a subfolder 'drupal' like in the tutorial instead of my usual workflow. In one way or the other, it seems like Storybook couldn't find the stories in the old setup. I'll keep on checking what the difference is, but for now: it works as designed.

Old (not working):
/projectname/.storybook
/projectname/.yarn
/projectname/web
/projectname/vendor
/projectname/.lando.yml

New (working):
/projectname/drupal/.storybook
/projectname/drupal/.yarn
/projectname/drupal/vendor
/projectname/drupal/web
/projectname/.lando.yml

@dgroene:
I've checked and rechecked, done a clean install and made sure the permissions were set. But it doesn't change anything in the outcome.

Web-Beest → created an issue.

If you want to use the session_id (in case of anonymous users), you should use the session id generated by the flag service in stead of the sessionManager. They are different ;-)

    $flag = $this->flagService->getFlagById('flag_id');
    $user = $this->currentUser;
    $session_id = $this->flagService->getAnonymousSessionId();

    $query = $this->database
      ->select('flagging', 'f')
      ->fields('f', [])
      ->condition('flag_id', $flag->id())
      ->condition('uid', $user->id());

    if ($user->isAnonymous()) {
      $query->condition('session_id', $session_id);
    }
    $result = $query->execute()->fetchAll();

Fix for broken blocks. This patch lets the FacetManager load all the blocks (disabled or not) but disables the rendering of the block that uses that facet. This way you can configure the blocks for all facets, but select which block should be rendered by disabling the facet.

I've got the same problem as well (in need of facets that can be disabled when needed). I've found one little issue in the code; when the facetblock is built, it returns an error because the facet is not active.

`Warning: Undefined array key "[facet_id]" in Drupal\facets\FacetManager\DefaultFacetManager->processBuild() (regel 323 van /app/web/modules/contrib/facets/src/FacetManager/DefaultFacetManager.php)`

This is due to the fact that the facet hasn't been built yet, but isn't available in the list of facets because it's not loaded. So I've added a check in FacetBlock::build that checks the facet status and returns an empty array if disabled.

Web-Beest → created an issue.

The problem with this is that only the text is selected to be shown in the modal window. Perhaps it is a better idea to not use a popup, but to insert the div as-is. You can add classes through the styles dropdown.

If you look at the demo block-widget plugin on the ckeditor page (https://ckeditor.com/docs/ckeditor5/latest/tutorials/widgets/implementin...) you can see a working example. The modal could still be used for simple or advanced editing of attributes, but without the content part.

I'm currently working on version that does this and I'll fork a new branch when I'm done.

Web-Beest → created an issue.

I've created a patch that fixes the compatibility check and the dropDatabase command.

generalredneck → credited Web-Beest → .

Updated the patch to change the order of the dependencies in composer.json and the info.yml file.

Forgot the drupal/color dependency in the info.yml myself :-/

You forgot a small part. Calendar depends on the core/jquery.farbtastic library as well, which is provided by the deprecated core/color module. So that needs to be replaced and make the contrib Color module a dependency.

You could also add the views_templates module in a lenient repository with the compose drupal lenient plugin, made by @mglaman (https://github.com/mglaman/composer-drupal-lenient)

Web-Beest → created an issue.

The patch from #4 works for me

First patch didn't apply properly.

Web-Beest → created an issue.

Thanks! I've merged your MR.