🇧🇷Brazil @halth

Okay. I'm seeing it's a conflict with the Gin admin theme... 🫠

Gin wraps the main table with a .gin-table-scroll-wrapper element, breaking the following CSS selector:

.field--widget-bert .tabledrag-toggle-weight-wrapper ~ table thead th:first-of-type,
.field--widget-bert .tabledrag-toggle-weight-wrapper ~ table tbody td:first-of-type {
  display: table-cell;
}

In case the maintainer feels like it's worth supporting Gin (for it's a widely adopted admin theme), I've submitted a PR with the updated selector.

halth → created an issue.

Here goes a warm Thank you! Much gratitude for this module.

Rodrigo, here goes a big thank you! This issue and patch just made my day. =)

Working fine for me.

Again, thank you!

Just applied the latest set of changes on top of MR!12.

Appreciate the community's effort in reviewing it.

Also, I believe this module will need a rewrite for full SimpleSAMLphp:2.1 compatibility, now that they support namespaced classes.

I don't know SimpleSAMLphp fully and I'm uncertain if "pattern named functions" (like sspmod_drupalauth_Auth_Source_External) are still supported.

I also ran by the https://www.drupal.org/project/drupalauth4ssp → module, which relies on the `drupalauth/simplesamlphp-module-drupalauth` composer project.

Even though it's not a 1 to 1 replacement (especially on the approach to set user attributes, which impose a hard rule with little-to-no customization), it seems like a more active project.

As the maintainer of this module is looking for support/new maintainers, wouldn't it be case the join efforts with the fellows from drupalauth4ssp?

What are your thoughts?

Thanks,
Heitor.

Just a quick status update that I'm still working on this. Should be opening a new MR in the next couple of days.

I'm having this same issue on a client project. I'll try to resolve this today.

Attaching a patch with a temporary, minimal "fix" that will import the default configuration from config/install in a hook update (Also created a MR for it).

Ideally, we would have a more sophisticated process of copying over the previous configuration entries over to their new names, whenever there's a 1-to-1 match.

Unfortunately I don't have the time to work on that now.

Hi everyone! 👋

In my opinion it absolutely needs an update hook for those updating the module. Besides the frustration of facing a WSOD after updating the module, it's bad user experience, which doesn't make justice for such a great module with over 10k users!

It does deserve a seamless upgrade path to its D10 compatible version.

I'll try to work on providing an update hook today.

I'll keep the thread posted.

Hi Alyssa! Thanks for reaching out.

You can contribute to this just by confirming you've tested the patch/MR above and flagging that it works for you.
That reinforces the Reviewed & tested by the community status, increasing the level of confidence on maintainers to accept it.

However, only an official project maintainer can merge the MR into the project and release a new version.
Unfortunately, they haven't paid attention to this issue yet.

I've tried reaching out to them on Drupal Slack directly, without success.

I think the best we can do for now is wait.

In case you can't wait on them, here are a few options you have to get around the D10 incompatibility issue:

- Make use of Composer Drupal Lenient to "whitelist" this module, so the version compatibility constraint won't prevent you from upgrading to Drupal 10:

"drupal-lenient": {
            "allowed-list": ["drupal/path_file"]
        }

- Apply the MR above as a patch using cweagans/composer-patches:

"patches": {
            "drupal/path_file": {
                "Issue #3289025: Automated Drupal 10 compatibility fixes": "https://www.drupal.org/files/issues/2022-06-16/path_file.1.x-dev.rector.patch"
            }
}

If this project gets abandoned moving into the future but you still need the functionality, you could also turn it into a "custom contrib" module, which pretty much consists of removing the Composer Dependency for this module, moving it to modules/custom and treating it as a custom project.

I hope this sheds some light on your way.

Patch on #4 worked for me as well. Definitely RTBC.

Anyone that could help me get this reviewed and eventually approved/merged?

Confirming that the patch provided by the @project-update-bot fixes the issue.

I've created a new MR.

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

I can confirm the proposed MR does fix the problem (which is indeed critical!).

Thank you @tostinni!

Just submitted a MR with the fixes proposed by @bvoynick on #5.

I'm in agreement with @bvoynick on CardinalityMediaLibraryWidget not being a D10 compatibility issue, since the MediaLibraryWidget class still exists on D10.

Okay, I'm sorry about the confusion.

I did a test in here and I can see that creating a custom base field on a custom entity is the use case you were referring to.

I can confirm that 1) I've been able to reproduce the error by following the instructions on the issue's description; 2) The patch on #3 by @stefan.korn did fix the error for me.

For other folks wanting to test this out, I suggest creating a custom content entity using drush gen content-entity and then using this sample field definition on your entity's baseFieldDefinitions() method:

      $fields['media_reference'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Media Reference'))
      ->setDescription(t('Example field'))
      ->setSetting('target_type', 'media')
      ->setDisplayOptions('view', [
        'label' => 'above',
        'type' => 'entity_reference_label',
        'weight' => -4,
      ])
      ->setDisplayOptions('form', [
        'type' => 'media_library_widget',
        'weight' => -4,
        'settings' => [],
      ])
      ->setCardinality(3);

Maybe I'm not following this... But here I go:

As far as I know, a media library field widget should only be available to fields of type media / entity reference.

I don't recall Drupal having base fields of type media / entity reference (Unless you create your own, of course).

Are you talking about this use case, specifically: Custom base fields of type media / entity reference?

Otherwise I cannot see how you would use a media library widget with a base field of a type other than media / entity reference.

Having said that, I haven't been able to reproduce the issue.

I would appreciate if you could provide more detailed instructions.

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

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

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

Okay, "sad" news.

Unfortunately this is not possible for the own nature of how this feature was designed/built.

The form that's rendered inside the modal is not contained inside an iframe (which would allow us to render it using the admin theme "in isolation"). Instead, it's rendered as part of the current page markup.

Loading the admin theme's stylesheet alongside with the main FE theme's stylesheet would cause a direct conflict causing unpredictable issues.

Creating a subset of the admin theme's stylesheet just to target this form rendered inside the modal would be a responsibility of the admin theme itself, since we cannot predict which admin theme the user is using.

If anyone else sees a different way to accomplish this that would not require a severe rewrite of the module, I'm happy to know what it would be.

I see what @SirClickALot point is...

When you're in the front-end of your website and click to edit a paragraph it renders the edit form using your FE theme, not the admin theme.

I also found it odd when I first tried this module.

This is something I would be happy to help with.

Let's see if I can come up with a fix in the next few days.