🇩🇪Germany @Anybody

Yes, I'd also prefer A as a nice improvement. B could be an additional option using a select like we for example know from field groups? Maybe as follow-up?

When solving this, either the formatter should get a "Use widget setting / default" option or the widget should generally override the formatter setting and the formatter should have a description informing about that like "Notice: If the widget allows overriding, this setting will have no effect."

I agree, but as nobody complained so far, we should wait for a MR to review, if someone needs it.

Thanks for the fix on 🐛 Micon missing schema for its fields definitions Fixed ! RTBC!

Nice work @Grevil. Some final additions and please check code-style. The complaints look weird to me, but we should ensure code style is fine! :)

Nice finding @jan kellermann that looks promising and totally makes sense! Thank you for the super quick reply!

anybody → created an issue.

@thomas.frobieter I just had the idea to contact @chi, maintainer of https://www.drupal.org/project/twig_tweak → and ask if we could maybe implement a merging solution that respects a certain field display formatter for drupal_field(). What do you think about that?

Whao, that was fast @itmaybejj very cool! 🎉

Great, thank you @itmaybejj!

Nice @itmaybejj! Turning off is perfect for me, thank you!

Fixed through 🐛 Formatter functions are missing the FileMediaFormatterBase parent:: calls Active

Nice!

Thanks all!

@grevil re #6 LGTM so far... let's keep this for now.

Great!

After thinking about this, I think a setting like this might be most helpful:

Run Editoria11y check on:

• Page load (default)
• Widget click

This setting allows running Editoria11y check on page load or when the user needs it, to prevent unwanted DOM manipulation.

Or add a Editoria11y per-user (cookie / local storage) setting to enable / disable Editoria11y auto-check on page load

Here's a similar, more generic issue: ✨ Add an "opt-in" mode per page (e.g. for Themers) Active that keeps Editorally available, but doesn't scan and modify the pages on load, but on user click.

I think both issues target a similar issue, but the solutions might be combined. The idea for an individual setting in the user profile (2) here might extend the other one, which might be a bit more generic.

anybody → created an issue.

anybody → created an issue.

Here's a related issue suggesting a setting to fix it: ✨ Allow configuring the widget position Active

anybody → created an issue.

Thanks @grevil, let's wait for @tomtech's feedback how to fix this best and correctly.

anybody → created an issue.

Just found these possible similar issues:

🐛 Ajax error because of PHP 7.4, Trying to access array offset on value of type null Needs review
#3238558: Multiple 'undefined index' and ' Trying to access array offset' notices in log when clicking on cog wheel →
#3231869: Form alter removes '#submit' and breaks Drupals expected array structure →

@grevil: I tried to unblock @thomas.frobieter and commented out all the field formatter settings code, but with no luck... the issue persists. So I'm wondering if we're inheriting this issue from FileMediaFormatterBase maybe?

Hopefully you'll be able to step-debug it easily, this is really strange... I thought the field selection for the poster image was maybe trying to handle non-existing fields or base-fields... but commenting out the code should have fixed that...

I'm also unsure why this hard-coded implementation exists:

  /**
   * {@inheritdoc}
   */
  public static function getMediaType() {
    return 'video';
  }

but didn't check it deeper, yet. Please do that. Maybe because by FileMediaFormatterBase this is more than just a file formatter... mhm. Anyway, if a custom "myvideo" media type exists with a video field, it should also work, but hard-coding would break it, right?

anybody → created an issue.

I guess something like

  // Get the field definition.
  $field_definition = $this->getFieldDefinition();

  // Retrieve the entity type ID and bundle.
  $entity_type = $field_definition->getTargetEntityTypeId();
  $bundle = $field_definition->getTargetBundle();

might be needed?

anybody → created an issue.

I got this message now when trying to configure the formatter:
Warning: Undefined array key "field_mime_type" in Drupal\field_ui\Form\EntityDisplayFormBase->copyFormValuesToEntity() (Zeile 615 ...

@grevil, I think best will be to step-debug that...
Hope it wasn't caused by 🐛 Fix autoPlay vs. autoplay typo in code Active but the module wasn't installed there before, so typically *should* not be the case.

Thanks @grevil. So should we wait for a reply from @tomtech or do you have a good idea for a smart MR?
Maybe we could detect the "merge" some way, plus some kind of module exists check for commerce_combine_carts?

Ok let's add a requirement for vidstack then!

Grml this breaks tests, as drowl_media_types config is not final... so let's postpone this, it's just a bonus.

anybody → changed the visibility of the branch 3507692-support-fieldgroup4-in to hidden.

4.x and 3.x are supported

anybody → changed the visibility of the branch 3507692-support-field-group4-2.x to hidden.

anybody → created an issue.

@it-cru totally makes sense, but is unrelated to this issue I suppose.

Using data attributes is also helpful for being able to manipulate them even at the theming layer / twig level, so I think this is fine! :)

@amh5514 and @ibis if I get your comments right, you also get exactly this error? Could you please re-check that and let us know, how frequently that happens? Any ideas for the reasons in your case?

Thanks @jsacksick and @grevil! At least we have some further information now. @grevil should keep track of this issue and let's also see if others run into it or if it's somehow specific to our case.

Regarding:

Lastly, eventually the user or some random js plugin removes the "skip_payment_creation" url query parameter, which would lead to a new payment creation at the end of the "onApprove" php callback

No, I can't see any case where that could happen and for our case I know, and you already confirmed that, so we can leave out that option.

Still it happens and presumably breaks checkouts for the affected users, so it needs to be fixed (some day, some way).

The module has no recorded usage yet, so we can still fix this. Yay!

posterLoad is btw. correct as of docs: https://vidstack.io/docs/player/components/core/player/

anybody → created an issue.

Just wanted to leave a note here, that we need something similar, but not for the alt-text, but for a subset of fields of the media entity to override in the referencing media reference field wiget.

https://www.drupal.org/project/media_library_media_modify → is close, but implements its own field type, which is a problem for existing sites. Instead, it should be a field widget for the existing media references.

Yup, the 4.0.0 is green currently... crazy. Any ideas welcome how to stabilize this.

Great, thank you @liam morland!

I also clarified that in the release notes and the short description now, thanks for your hint!

Hi @fago, @caesius is right, while this is a major version change, there were no breaking changes and requiring ^10.3 (which is actually the supported release besides ^11) is the only relevant change.

Nonetheless, I totally understand your point, and we marked 3.x as supported for some more weeks, this was probably a bit too fast ;)

BTW I think we have several places, where a description would make sense:

• In the payment method selection - as explanation for the payment method
• On the payment page - to show details on the chosen payment and process
• On the complete page - to show further instructions

Most of this applies to all payment methods, I think. So maybe should really go into Commerce and not into the individual payment module?

Mhm I'd still vote to cover all potential cases, like in 11. It's not untypical to show both, the label and the Logo and furthermore a string-based setting is extensible in the future in contrast to a checkbox.

Hi @avpaderno yes indeed I'd still be interested. We're actively using the module and @droath doesn't seem to be very active currently. Furthermore I'd like to opt the module into security advisory policy.

Thanks!

Nice, let's also solve that!

Thanks @Grevil: I agree and I think that (breaking) change is okay here, because it's more a fix of expected functionality and I don't really think anyone should heavily rely on this request logging.

If we want, we could add an empty update hook to just inform developers about the new setting.

anybody → created an issue.

anybody → changed the visibility of the branch 3490746-fix-coding-standard to hidden.

anybody → changed the visibility of the branch 4.x to hidden.

anybody → changed the visibility of the branch 8.x-3.x to hidden.

Reopened to finally also fix eslint in 3490746-fix-eslint

Thanks, we indeed need to fix that. My impression is that some days or weeks ago the test were green consistently. Any ideas for the reasons?

We should check if it's still an issue with 4.x and prepare a MR please.

Please retry with latest 4.x - does the issue still exist?

Thank you! Merged! :)

@dianacp which version are you really using? You selected 8.x-1.0?

Yup, closing this as duplicate!

Is this possibly a duplicate of 📌 Add "Machine name" column in field_ui to align with latest core Active ?

Please try with the latest 4.x release.

@lazzyvn thanks for your report. Could you give some more details on the effect of this bug, so we can reproduce and fix it more easily? Please use the provided issue template.

As of #11 - this is close to the finish line :)

Thanks @efpapado totally makes sense to me code-wise. Let's see what the maintainers think.