🇫🇮Finland @iamfredrik

Patch does not work correctly for me.

In my case the default language is Swedish.

I have a node with path /sv/aktiviteter

/router/translate-path?path=/en/aktiviteter

correctly returns the resolved path /en/activities

but it's unable to translate back and /sv/activities returns:

{"message":"Unable to resolve path \/sv\/activities.","details":"None of the available methods were able to find a match for this path."}

iamfredrik → created an issue.

Sorry for the confusion. This issue was created in 2021 so I don't have the actual image used back then, but I'd say any dark background image should trigger the same issue. I tested it now using the color selections and it still triggered the issue.

You don't need an image. Just select black or any dark color as background.

Please view the screenshots of the cover block element before and after saving the node. Notice how the `is-dark-theme` class is missing from the saved output.

I received the same error when updating to D10. It was because I was using a patch from here: https://www.drupal.org/project/views_bootstrap/issues/2898490#comment-15... ✨ Support for multicolumn carousel Needs review

I just uploaded an updated patch https://www.drupal.org/project/views_bootstrap/issues/2898490#comment-15... ✨ Support for multicolumn carousel Needs review

Oops. There was an error in that patch. Here's an updated patch.

When updating to Drupal 10 I got the same error described here: https://www.drupal.org/project/views_bootstrap/issues/3362994 💬 views-bootstrap-carousel Unexpected token "name" of value "if" Active

Created a patch.

@Anybody, yes of course I have to adapt the JS to suit my scope. Just wondering why it unexpectedly got added after updating to 3.1.4. According to the documentation the t class is an optional anchor text class, so it would make sense to make it optional. Thanks!

@Anybody I have a decoupled front-end so there is no additional JS running that I haven't added myself. The t class was not there before updating to 3.1.4, so why has it been added? Can it be made optional?

3.1.4 adds a span with class="t" that I don't want.

<span class="spamspan"><span class="u">firstname.lastname</span> [at] <span class="d">mydomain.com</span><span class="t"> (firstnamedotlastnameatmydomaindotcom)</span></span>

How do I get rid of it? Temporary workaround:

.spamspan > .t { display: none; }

Works if I apply patch #40 from:
https://www.drupal.org/project/commerce/issues/3051241 💬 User is sent to 403 page after successful payment (anonymous checkout) Needs work

So it's seems deprecating queue logic should not have been done until that issue is fixed. Please update the documentation that the patch is required.

Doesn't seem to be working anymore after updating to Commerce Payment Paytrail 3.0.0.

How to reproduce:

Create an order that returns access denied by following the steps in #13

Order is not finalized and running cron does no longer finalize the order.

@PapaGrande, I tried both workarounds and none of them worked.

I tried implementing the presave function in #8 but couldn't get it to work. I put the code from #8 in mymodule/src/MediaImage.php, and then the following code in mymodule.module.

 use Drupal\Core\Entity\EntityTypeInterface;
 use Drupal\Core\Entity\EntityTypeManagerInterface;

function mymodule_entity_type_build(array &$entity_types) {
  if (isset($entity_types['media'])) {
    $entity_types['media']->setClass('Drupal\mymodule\Entity\MediaImage');
  }
}

Help with implementing the workaround correctly would be much appreciated.

Thank you very much for that link. I will give the patch a try.

Okay thanks. The issue with the return url being opened in the wrong browser still needs to be addressed, because the 'access denied' message leads to a confusing customer experience. Is it Paytrail's or Mobilepay's responsibility to fix it?

The queue item gets removed only when cron is run after which the order gets the payment info added, but the order is not moved from draft state to completed order if cron is run 3+ hours later (could be sooner, but haven't tested).

Steps to reproduce:

1. Disable cron
2. Create an order by following the steps outlined in #13
3. Verify that the queue item exists (select * from queue;)
4. Wait 3+ hours
5. Verify that the queue item still exists (select * from queue;)
6. Run cron manually
7. Verify that the queue item is removed (select * from queue;)
8. Check if order is placed or still in draft mode

I believe the queue item gets removed only when cron is run, but I'd have to wait 3 hours to verify.

Expire says 0.

It is no longer in the queue after cron run, so I have to retest.

I have now tested the steps in #13. The order is placed after cron run, but not if cron is run after 3 hours (standard cron setting in Drupal). So the conclusion is that the notify callback expires after some time within 3 hours after the order is placed.

I looked up all from the list in the access log. They were all mobilepay except one from almost a year ago which was aktia_paytrail.

I checked the access log for '2007' and the checkout-provider is Osuuspankki, so the problem apparently is not limited to MobilePay.

I checked a couple of those with select * from commerce_order where order_id = 'XXXX'; and one thing they have in common and is different from ones that are actually placed is that the following tables are NULL:

order_number
total_paid__number
total_paid__currency_code
placed
completed

Here's the return of that SQL query.

Yes, it has.

I seem to have spoken too soon. For some reason it didn't work on my local development site, but it does work on the production site now.

Just updated to 2.0.1 and D9.5.8. Alas, the bug is still there.

Found it:

/payment/notify/paytrail?checkout-account=9XXXXX&checkout-algorithm=sha512&checkout-amount=1500&checkout-stamp=4567debe-0c93-4f20-a1f8-9abe2023e810&checkout-reference=1983&checkout-status=ok&checkout-provider=mobilepay&checkout-transaction-id=e26b303c-da17-11ed-adbd-a7c59d4b19c0&signature=b460d0fdcc1d7928c99a366789d134d1b8e77e78d11f1234ca0edf7650a5f184a4d68292b214babebd92e24df71589cc0e1e09a762aa71541b8c107cf110afee HTTP/1.1" 200 554 "-" "Paytrail Payment Registration”

I found lots of checkout-reference entries, but none that matched '1983'.

Thanks. The data field only contains the following string: "0x613A323A7B733A32313A22706169645F6576656E745F64697370617463686564223B623A303B733A32303A227465726D735F616E645F636F6E646974696F6E73223B693A313B7D"

I have no idea, since there is no order registered in the shop. If you have a sql query for retrieving the cart order, I could try that.

The queue does not contain anything from the date the order failed.

iamfredrik → created an issue.

Don't have time to test right now. I trust that it works if you say it works. The site in question is very basic and uses the Claro admin theme and no advagg. Enclosed is a screenshot of the console errors when Gutenberg whitescreens. What idea what could cause these issues?

1. No, clearing cache did not help.
2. Yes, the issue exists only with aggregation enabled as mentioned in the problem description.
3. Have not tried. We have this module installed on a few sites, but have since moved away from using it because of too many issues.

iamfredrik → created an issue.

You may remove the option by default for backwards compatibility, but please make the option to hide fields into a setting. My use case is that I have a bunch of different content types with different fields. I use the grouping patch from here https://www.drupal.org/project/drupal/issues/3251937 → to group the fields by content type. In this case it doesn't make sense to show empty fields for those content types that don't have the fields.