tuutti → made their first commit to this issue’s fork.
tuutti → created an issue.
I've ported the Drupal 7 version of this as suggested in #9. We should probably add a proper test coverage for this tho.
We've been using this for a couple of months now and it seems to work.
Yeah, this doesn't seem to work with any other kind of discount than -100% off, but neither does the current implementation tho.
Looks like we don't have a test for shipping promotions. Using ->getAmount() probably won't work with partial discounts, like fixed 5€ off or -10%, but I'm not sure without actually testing this.
I don't have access to my commerce setup at the moment, so I'll get back to this later this week.
Ah, the type is probably populated by packages.drupal.org (https://packages.drupal.org/files/packages/8/p2/drupal/flysystem_azure~d...) if it does not exist and that's why the original module works but the fork does not.
It should work now.
We ended up forking the AzureBlobStorageAdapter class from upstream and removing the league/flysystem-azure-blob-storage dependency altogether since the 1.x version is not very likely to receive any updates.
The latest version requires flysystem 3.x, but drupal/flysystem only supports 1.x at the moment.
Nevermind.
This module has a dependency to league/flysystem-azure-blob-storage 1.0.0 and it requires guzzlehttp/psr7 ^1.5. while core requires guzzlehttp/psr7 ^2.4.5.
Discussed #162 with @alexpott and we agreed that even though that is a pretty strange use case, we should drop the ->isTranslatable() check.
I incorrectly assumed earlier this would work just by removing the isTranslatable() check, but it doesn't work with other menu link plugins or Not applicable/Not specified links because they will always fail to hasTranslation() check and get removed, so we definitely need it.
After digging a bit, the root issue seems to be how ContentEntityBase::isTranslatable() works without content_translation module.
At the moment ::isTranslatable() works like this:
public function isTranslatable() {
// Check the bundle is translatable, the entity has a language defined, and
// the site has more than one language.
$bundles = $this->entityTypeBundleInfo()->getBundleInfo($this->entityTypeId);
return !empty($bundles[$this->bundle()]['translatable']) && !$this->getUntranslated()->language()->isLocked() && $this->languageManager()->isMultilingual();
}
So basically it checks if:
1. Entity bundle has translatable=true. The "translatable" key gets populated in content_translation_entity_bundle_info_alter for entities that has content_translation = enabled third party setting
2. The entity's original language is not "locked", so basically either "Not specified" (und) or "Not applicable" (zxx)
3. The site has more than one language enabled
Meaning it will always fail to step 1 without content_translation module.
I think there are a couple of ways to fix this, assuming we want to support this use case:
1. Fallback to entity type's translatable annotation if the bundle info has no translatable key. Something like:
// \Drupal\Core\Entity\ContentEntityBase
public function isTranslatable() {
// Check the bundle is translatable, the entity has a language defined, and
// the site has more than one language.
$bundles = $this->entityTypeBundleInfo()->getBundleInfo($this->entityTypeId);
if (!isset($bundles[$this->bundle()]['translatable'])) {
$bundles[$this->bundle()]['translatable'] = $this->getEntityType()->isTranslatable();
}
return !empty($bundles[$this->bundle()]['translatable']) && !$this->getUntranslated()->language()->isLocked() && $this->languageManager()->isMultilingual();
}
I committed this change earlier today and you can find the test result here: https://git.drupalcode.org/issue/drupal-2466553/-/pipelines/29526,
2. Override ::isTranslatable() in \Drupal\menu_link_content\Entity\MenuLinkContent with something similar.
Both changes might be out of the scope of this issue though.
I tested this briefly without content_translation module, added a couple of menu links in different language and the "untranslated" links are hidden if you remove the isTranslatable() check.
It also seems to hide zxx and und links because hasTranslation() returns FALSE for them, as expected. One way to fix this would be to always return TRUE for locked languages in Drupal\menu_link_content\Plugin\Menu::hasTranslation():
public function hasTranslation(string $langcode): bool {
if ($this->getEntity()->language()->isLocked()) {
return TRUE;
}
return $this->getEntity()->hasTranslation($langcode);
}
As a side note, the ->isTranslatable() check seems to fail in ContentEntityTranslation::isTranslatable() because the translatable key is populated by content_translation module in function content_translation_entity_bundle_info_alter(&$bundles).
It's perfectly valid to have multilingual menu links without content_translation module, although not very common 🤔
I tested this briefly without content_translation module, added a couple of menu links in different language and the "untranslated" links are hidden if you remove the isTranslatable() check.
The current implementation doesn't have a dependency to menu_link_content module anymore so I've moved it under system module since the whole functionality is tied to SystemMenuBlock now.
We have Drupal 9+ version of this module here: https://github.com/City-of-Helsinki/drupal-module-stomp and would like to maintain the module.
We've been using this patch for a couple of months with D10 now.
tuutti → created an issue.
Is the current 2.0.0-alpha1 stable enough to use? What are the reasons / blocking issues / ... preventing a stable or at least beta/RC release?
It is. There's no other reason preventing it than just me being lazy.
2.0.0 release should be up now, thanks for reminding me.
I added a 120 second delay for notification callback in 📌 Deprecate queue processing Fixed , which should eliminate the original issue too. Does the delay not work for you?
Looks like create payment API has callbackDelay field. We can probably deprecate the queueing before next commerce release by delaying the callback polling: https://docs.paytrail.com/#/?id=request-body
I've made a follow up task for this 📌 Deprecate queue processing Fixed .
I don't have any means to verify if that's even the real culprit, but it's probably something along those lines and it's probably something that should be fixed on Commerce itself. I found this issue 💬 User is sent to 403 page after successful payment (anonymous checkout) Needs work , but it doesn't seem to be very active at the moment.
Actually, looks like the original issue 🐛 The changes made to the order on the onNotify method are not applied on the onReturn method Fixed (the reason why we even process orders via cron ) seems to be fixed now. The whole queue logic can probably be removed on next Commerce release, which should automatically fix this issue.
Looks like my guess was right. The commerce payment module seems to rely on core's KernelDestructionSubscriber.php to trigger PaymentOrderUpdater service that eventually triggers the OrderPaidSubscriber that "places" the order when the order is paid in full.
Looks like the KernelDescturctionSubscriber is never triggered when AutomatedCron is run (or they are run in wrong order), leading to PaymentOrderUpdater.php never being run.
I don't think there's much that can be done on our side. Easiest way to fix this is not to rely on automated_cron module and trigger the cron some other way:
https://www.drupal.org/docs/administering-a-drupal-site/cron-automated-t... →
My best guess for now is that this has something to do with core's automated_cron module conflicting with some commerce functionality. I vaguely remember seeing some order processing done in TERMINATE kernel event and the automated cron is triggered on TERMINATE kernel event too: https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/aut...
I was able to reproduce this on my test site too. I'll look into this a bit more tomorrow.
Does the cron fail or does the queue item just get removed before it's actually processed (after that 3 hour limit you mentioned earlier)? The expire date should only be updated when the item is actually claimed: https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/lib/Drupal/...
Does your queue items get an expiration date even if you don't run cron? (select * from queue;). The initial item shouldn't get an expiration date
You can find orders that are not placed, but has a payment marked as completed with this SQL query:
select o.order_id from commerce_order o left join commerce_payment p on o.order_id = p.order_id where o.state = 'draft' and p.state = 'completed'
Weird. The order should be "placed" by payment module's OrderPaidSubscriber when the order is paid in full: https://git.drupalcode.org/project/commerce/-/blob/8.x-2.x/modules/payme...
I tested this using test credentials:
1. Created an order
2. Used Nordea as payment method
3. Copied the URL from "Simulate success to merchant" button:
4. Opened the URL in incognito mode and the return page gave an access denied error:
5. The order is now in "draft" status with no payments
6. Paytrail called the notify callback and the order is "placed" after I ran cron:
Did you check if the order has any payments made (/admin/commerce/orders/1983/payments)?
Can you check your web server's access logs if there's any entries matching /payment/notify/paytrail and checkout-reference=1983, something like cat /your/access.log | grep '/payment/notify/paytrail' | grep '1983'.
I'm trying to figure out if Paytrail actually called the notificiation callback at some point.
Maybe something like drush sqlq "select * from commerce_order where order_id = '1983'"
Does the order's data field contain anything with commerce_paytrail_maximum_captures?
It seems to fail to this access check: https://git.drupalcode.org/project/commerce/-/blob/8.x-2.x/modules/check...
I'm wondering if this has something to do with MobilePay app itself, like if the user used Chrome to create the order, but the MobilePay app returned user to default browser where the cart session does not exist (Safari for example), leading to an access denied error.
Paytrail should call the notify callback even if the return callback fails. The failed order is queued and be processed by Drupal's cron.
You can check if it's stuck in queue with something like (assuming you're using database queue): drush sqlq "select * from queue;".
This should be fixed in 3.x.
This should be fixed in 3.x version. I haven't had time to test it properly yet tho.
This should be fixed in 3.x branch now. I haven't tested it properly yet tho.
tuutti → created an issue. See original summary → .