Porta Westfalica
Account created on 9 May 2008, almost 17 years ago
  • Drupal Software Engineer & Developer, Project Management at DROWL.de 
#

Merge Requests

More

Recent comments

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

anybody created an issue.

🇩🇪Germany Anybody Porta Westfalica

@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

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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).

🇩🇪Germany Anybody Porta Westfalica

@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.

🇩🇪Germany Anybody Porta Westfalica

Thank you rszrama :)

🇩🇪Germany Anybody Porta Westfalica

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...

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

Nice, RTBC!

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

3y later

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

anybody created an issue.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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?

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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...

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

@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! :)

🇩🇪Germany Anybody Porta Westfalica

@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!

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

Thank you, dom!!

🇩🇪Germany Anybody Porta Westfalica

@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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

anybody created an issue.

🇩🇪Germany Anybody Porta Westfalica

Clearer versioned patches attached.

🇩🇪Germany Anybody Porta Westfalica

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!

🇩🇪Germany Anybody Porta Westfalica

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?

🇩🇪Germany Anybody Porta Westfalica

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 )

🇩🇪Germany Anybody Porta Westfalica

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?

🇩🇪Germany Anybody Porta Westfalica

Latest MR as patch attached.

🇩🇪Germany Anybody Porta Westfalica

Nice cleanup! :)

🇩🇪Germany Anybody Porta Westfalica

@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)?

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

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!

🇩🇪Germany Anybody Porta Westfalica

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?

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

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?

🇩🇪Germany Anybody Porta Westfalica

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.

🇩🇪Germany Anybody Porta Westfalica

@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.

🇩🇪Germany Anybody Porta Westfalica

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

🇩🇪Germany Anybody Porta Westfalica

@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! :)

Production build 0.71.5 2024