🇨🇦Canada @arakwar

While I can understand the logic behind this, I have to point out that it can break existing themes... Having no way of turning that new behavior off is an issue.

My bad.

If you use the NBSP module, make sure its configured to process the text before you remove the P tag. So in your text editor settings, the NBSP filter has to be before the strip P filter.

arakwar → created an issue.

Hi!

It's exactly the same change I was currently testing, so I can confirm that it works :)

arakwar → created an issue.

I tested one of our project without the patch and it created more issues for us.

I added the missing function back in the module. I also applied patch #46 on MR !38, just to make it easier to continue to work on this issue until it's resolved.

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

Adding issue https://www.drupal.org/project/drupal/issues/3180702 ✨ Export block UUID with custom Layout Builder blocks Needs work as related, because we also can't use both patches at the same time.

#6 works for me.

Uninstall both Rules and Typed Data at the same time and you'll be ok.

Either Rules isn't truly uninstalling properly, or Typed data has an issue when a module using it is uninstalled.

I have just noticed your issue in my project. Seems we are using your patch, and I just created a new issue fixing the last warning :

https://www.drupal.org/project/az_blob_fs/issues/3460622 🐛 ImageStyleDownloadController::deliver() now takes a string of the expected scheme for derivatives as a required parameter Active

arakwar → created an issue.

To add more details on the next person who'll find this trough Google :

We had a contrib module, admin Tooltips, who had a langcode key in one file in their config/schema folder.

We found it by running a search on all **/config/schema/*.yml files, on the langcode key. Look for anything that isn't a field definition and remove them.

Once we did that, it solved our issue.

While I understand that this shouldn't happen as config schema should be clean, maybe the safeguard around this and the error message could be a bit more descriptive of the issue? I feel like I found the comment #6 by luck while it's exactly the right answer to our issue.

Is this still an issue in Drupal 10.2 (and 11) ?

While trying to redo the patch for 10.2/11, I can see core changed and seems to be close to what the patch does, but for now I can be 100% sure of it.

arakwar → created an issue.

arakwar → created an issue.

Adding the 'langcode' elekment there does work in hiding the langcode change, but still imports those changes in the website. So this would only be a UI fix for now.

I wonder how complex it would be to apply an existing translation on top of a configuration before importing it. Like, if my feature has English as a base and French as a translation, but the target site is in French as a base, then applying the French translation of config on the import could make sense.

But it feels like a huge change...

We have the same challenge here, some of our sites have a different base language from our "source" site.

But a clarification needs to be made here : The "Language" option enabled here is about Language configurations, not the langcode in config files.

So the site will exclude any Language config, so if one of your config requires the "language.en" config, it won't be part of the feature export.

I'm still trying to figure out how to handle the langcode difference.

arakwar → created an issue.

arakwar → created an issue.

I got the same issue while trying to limit logins to my main "Domain Access" domain name.

The code we're trying to implement :

/**
 * Implements hook_form_alter().
 */
function domain_login_disable_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'user_login_form') {
    /** @var \Drupal\domain\Entity\Domain $active */
    $active = \Drupal::service('domain.negotiator')->getActiveDomain();

    if (is_null($active)) {
      $active = \Drupal::entityTypeManager()->getStorage('domain')->loadDefaultDomain();
    }

    if (is_null($active)) {
      // If there's an issue with domain, we won't block the login form.
      return;
    }

    if (!$active->isDefault()) {
      $form['#access'] = FALSE;
    }
  }
}

When going trough a page request with Xdebug, we can see that in core/lib/Drupal/Core/Render/RenderCache.php, in the getCacheableRenderArray() function, the $elements array doesn't have a #markup element.

Adding $form['#markup'] = NULL; in our function right after we set #access to FALSE fix the issue.

Is it an intended behavior?

We're using the Drupal 9.4.14 version with Domain 2.0.0-beta1, and have the same issue.

I have a situation where I'd like some users to be allowed to publish content on a second domain, but have everyone go trough the "main" domain to create content.

Is it something that this patch would help to cover ?

Isn't this the base behavior we want? As per the description, the module ignores config at importation.

This is the behavior it had for a while, but now it seems broken...

Requiring the package manually does not seems to fix the issue in the latest version...