🇩🇪Germany @Anybody

anybody → created an issue. See original summary → .

Just asked myself the same and found this. I guess it might be really useful to put this comparison on the project page?
XB will be widely used in the future, so I think people will look for exactly this comparison, when deciding for a solution.

@Maintainers: There's still no stable D11 compatible release. Could you please tag one? Thanks!

anybody → created an issue.

@lrwebks: Indeed the content ad entities are not yet translatable!
It's also part of the annotations, so please add this when making them bundleable!

See: https://www.drupal.org/docs/develop/translating-custom-entities →

I think most of this will be cleverly solved by ✨ Turn ad sizes into config entities Active .
We can afterwards discuss what else might be needed and someone who needs it can create a MR. Until that, let's set this issue POSTPONED on ✨ Turn ad sizes into config entities Active

We should call these "ad placements" or something like this perhaps, so that the site owner can decide how to use it with more flexibility.

Ad placements can this way be either created just by size, e.g. "Rectangle" or can even be more precise for a region, like "Content area rectangle".

They should therefore have a human-readable label and a machine name. The ad placement can be selected in the ad block (eventually multi-value) and in the ad to publish there (eventually multi-value).

@SocialNicheGuru if you're still interested, please create a MR that allows replacing the image field with a media field as custom solution or using a submodule. In effect, I think of adding output support for a certain media field name, if it exists. If it doesn't exist, the image field is used.

Maybe that could be done in a preprocess hook for example or directly before the theme() call.

If you don't need this any more, please close the issue. We have no need for this and I don't think you typically want the advertisement banners in media library.

Nice find!

anybody → created an issue.

Thank you rszrama :)

Yep, that's also my point. If we put this functionality into a submodule (favourite) or at least a setting to opt into, I'd be happier...

✨ Glossify + Paragraphs: Multiple glossary links instead of one per node Postponed: needs info looks related?

Honestly I'm personally not a big fan of this additional complexity, but let's wait for further maintainer and community feedback.

Nice, RTBC!

What here is still needed after ✨ Exclude tags configuration Needs review was merged? Could we split the rest off?

Thanks for the quick feedback @lazzyvn - we'll add a MR for better Gin support, as it's the most widely used Drupal Admin theme.

As @Grevil just pointed out correctly, in our mental model we have

- In stock
-- [possible other in stock sub-statuses]
- Out of stock
-- Incoming (preorder)
-- [possible other out of stock sub-statuses]

And we could then map the result combination for Google Merchants.

Before touching anything here, we first need to discuss the final expected outcome.

anybody → created an issue.

Added https://www.drupal.org/project/cookies/ →

I don't think this should be the job of this module. The module should just trigger the delete and a referential integrity functionality from core or contrib should solve this, just the same as if someone manually deletes the node.

A huge +1 on adding support for all entity types. Now that even Drupal Core has support for revisions on

• Taxonomy Terms
• Media

plus revisions on custom entities shows the clear demand for a solution to maintain revisions.

I couldn't find any module solving this yet and node_revision_delete seems to be most feature-rich one candidate. Even better would be to solve the most important parts in core: #2925532: Provide bulk action to delete all old revisions of an entity →

See https://git.drupalcode.org/issue/revision_cleanup-3519218/-/blob/3519218...

Until this is implemented for all entity types, the module page should clearly point out, that only nodes are supported so far.
With all entity types that have revision support in core now like Media and Taxonomy terms, revision cleanup may be really important.

anybody → created an issue.

Using the interface instead of the class is correct! Should be merged.

anybody → created an issue.

Aus of #2

3y later

@marjose would you mind creating a MR with the proposed fix?

anybody → created an issue.

@bgreco please use a MR, not patches. Thanks!

I guess we should start with a fresh fork / MR. I don't see any reasons for modifications on the PHP-side. We already have a "component" = field formatter / twig template as abstraction layer that acts consistently. And that's basically what we want?

I can still reproduce the issue with the Glossary view. Its letter navigation is non-ajaxified. Let's wait until someone can confirm this, before reopening. https://www.drupal.org/project/drupal/issues/2877958 🐛 Glossary View: Ajax doesn't work Closed: duplicate

Thanks @cilefen - I just downgraded and have very busy days currently, would be great if someone else could test it.

But I guess YES and thought the same...

Pipeline is green, maybe the Draft status should be removed from the MR?

Hi and thanks for the feedback. I'm also unsure if comment is really essential. Still it's not worth a long discussion and I'm fine to keep it, if it helps someone. It's much personal preference and learnings, I also like ways to keep (admin) notes for entities... still it doesn't have to be within the entity itself.

Despite that, I totally agree that variables should be removed. A static string would be fine as comment and can / should be generated at the time of creation.

I can confirm that downgrading to Drupal Core 10.4.5 fixes the issue.
This breaks commerce_reports, for example.

I can also confirm this issue using commerce_reports. This is a major problem as these reports are essential for the stores.

Thought about this again and while the idea behind is still great, I think this doesn't belong into this module, but into a much more generic field reports module (e.g. https://www.drupal.org/project/issues/field_tools → ) or core. The report should show the used field formatters grouped per entity display. Same should exist for widgets then.

So while I totally like and support the idea behind, it should not be implemented in fences and I'm just keeping this open to save the idea, but see this as WON'T FIX HERE.

@murz yes, that's by design. There are definitely cases for both. Feel free to add another formatter setting to use the reference on the preset instead. We decided to not implement that ourselves. In 95% it's good enough for us and the reference alternative also has drawbacks, so the user needs to decide per formatter then. (That's why it's called "Presets")

I disagree with the proposed solution a bit. Maybe there's a better way with backwards compatibility. I imagine something like a "Customize values" checkbox after selecting a preset, which then shows the fields. Otherwise the fields are hidden when selecting a preset and reference is used.

Let's first discuss that in detail and sketch the UX, before you invest time into the implementation. Thanks and great ideas! :)

@murz: Totally agree with you and @thomas.frobieter. Feel free to create a MR. If it's a workaround that introduces smells, let's please put this into a separate submodule, so it's clearly encapsulated and can be removed easily one day, if Core will fix it.
Thanks!

Use composer require 'drupal/convert_bundles:2.0.x-dev@dev' to install the dev version in D11.

As of #14 it looks like it needs an update hook to safely remove that entry?

Thank you, dom!!

@dom. sorry for pinging again. Issue is RTBC'd and the MR looks fine to me and is not risky. So perhaps merge and release this fix? vbo is widely used.

I guess the fix is self-explaining and fixes the issue?

anybody → created an issue.

I think this is solved. Might also have been an issue on the reporters side.

As just discussed, I think a table would make a lot of sense to be more like watchdog and get one result per line.
Maybe we could even make it sortable, I'm not sure yet, how difficult that would be.

Hi, we just tried the Stripe Express Checkout Element and these are our observations:

The wrappers are correctly placed on the cart page:
<div id="payment-errors"></div><div id="stripe-express-checkout-element" data-drupal-selector="edit-stripe-express-checkout-element"></div>

The JavaScript initializes the Express Checkout within the element:

<div id="stripe-express-checkout-element" data-drupal-selector="edit-stripe-express-checkout-element" data-once="stripe-processed" class="StripeElement">
    <div class="__PrivateStripeElement" style="margin: -4px 0px !important; padding: 0px !important; border: medium !important; display: block !important; background: transparent !important; position: relative !important; opacity: 1 !important; transition: height 0.35s !important;">
        <iframe name="__privateStripeFrame3093" frameborder="0" allowtransparency="true" scrolling="no" role="presentation" src="https://js.stripe.com/v3/elements-inner-express-checkout-with-shared-39bb4efb86b60c9971566f493d873828.html#__shared_params__[version]=v3&amp;wait=false&amp;rtl=false&amp;publicOptions[paymentMethods][applePay]=never&amp;publicOptions[paymentMethods][googlePay]=never&amp;publicOptions[paymentMethods][amazonPay]=never&amp;elementsInitSource=stripe.elements&amp;componentName=expressCheckout&amp;keyMode=live&amp;apiKey=pxx&amp;referrer=https%3A%2F%2Fwww.example.com%2Fcart%3FWDEBUG&amp;controllerId=__privateStripeController3091" title="Sicherer Rahmen für schnelle Bezahlvorgänge" style="border: 0px !important; margin: -4px; padding: 0px !important; width: calc(100% + 8px); min-width: 100% !important; overflow: hidden !important; display: block !important; user-select: none !important; transform: translate(0px) !important; color-scheme: light only !important; height: 80px; transition: height 0.35s, opacity 0.4s 0.1s;"></iframe>
    </div>
</div>

But the iframe is empty (white) and shows no payment methods.

So either I'm doing something wrong or miss something. Maybe it needs additional documentation for the setup?

Because of https://docs.stripe.com/elements/express-checkout-element#supported-brow... I tried it in Firefox and Chrome as logged-in user.

Maybe other users will run into similar issues in the future, so I hope my comment helps.

anybody → created an issue.

Clearer versioned patches attached.

Based on the last comment I'm linking ✨ Support Payment method Bancontact Active . Still the original reporter didn't say, which payment method is affected in his case!

Thanks, I agree this looks like a major bug. Another thing I experienced is, that different payment methods are shown in Stripe when the checkout is entered for the first time and on a later call. Typically in the second case, only Credit Card is shown, maybe important information is not being provided to Stripe on a subsequent call, similar to the balance?

We're having similar trouble and debugging this at https://dashboard.stripe.com/settings/payment_methods/review I get the following feedback:

Klarna: The customer's country is "US` which is outside the countries you can accept with `klarna` for the provided currency `eur`. Supported countries: AT, BE, DE, ES, FI, IE, IT, NL, FR, GR, PT.
(as written in: 🐛 billing profile info is never saved in stripe Active )

I guess we're having similar issues. For unknown reasons, some payment methods are not shown.

Debugging this at https://dashboard.stripe.com/settings/payment_methods/review I get the following feedback:

• Klarna: The customer's country is "US` which is outside the countries you can accept with `klarna` for the provided currency `eur`. Supported countries: AT, BE, DE, ES, FI, IE, IT, NL, FR, GR, PT.
• Bank transfer: You must provide a customer when creating or updating a PaymentIntent with a "customer_balance` PaymentMethod.

The shipping and payment address is definitely in Germany (DE), using commerce_shipping, so it's totally unclear, why "US" is detected at Stripe.

Should

PaymentIntent with a "customer_balance`

already work and is that maybe also related to the address issue?

Should I open a separate issue for that or do you agree this might be related?

Latest MR as patch attached.

anybody → created an issue.

anybody → created an issue.

Nice cleanup! :)

@lrwebks I don't remember anymore, maybe you could post a screenshot of the current situation here?

One thing that would make sense to me is to put each message into a "details" element that can be expanded, collapsed by default with basic information in the header (message title and time)?

See the link on the project page: https://git.drupalcode.org/project/devel_debug_log/-/pipelines

Yes, it's green. Just some code style issues that could be fixed in a subissue.
But the existing test doesn't really test much. Also our typical base test isn't there. This module could need some Unit Tests, I think.

I can also see that the table is automatically dropped just fine when uninstalling the module, even without our uninstall hook.

This means the MR fix would not be needed. So I think this is an indiviual issue in the authors page. So let's close this cannot reproduce.

Thanks @lrwebks!

Nice, thank you @lazzyvn - we'll have a deeper look at that and update the status here accordingly!

Maybe a screenshot or description of the feature on the module page would be nice?

Is #22 the suggested approach? Or are there plans to include Metatags in Webform in any way?

anybody → created an issue. See original summary → .

Just ran into a case where glossify adds tooltips in headings (hX) - so yes, we definitely need a way to exclude this. @grevil could you review this finally, please?

Well I think, there might have been a reason for that line, which we need to keep, but we should not alter the original value. I'm not deeply into this though.

@grevil: We're running into this in a client project, maybe you could have a look in the next days? See my comment in the MR.

anybody → created an issue.

Cool, thank you @tomtech! Then we'll also try it now! That sounds amazing, very much looking forward to the official release!

@vmarchuk, @rszrama is there work going on in the background on this issue or any further plan or should we simply review & test it and send feedback as-is?

Thank you! :)

anybody → created an issue.