jsacksick → made their first commit to this issue’s fork.
jsacksick → made their first commit to this issue’s fork.
I am sad now. I simply need to add a small handling fee, but it is not to be taxed. I did this in commerce 1.x with rules as I recall
You can either write your own order processor than runs after the tax order processor. Or alter the order processor defined by this module so the Fee is applied post tax calculation.
That means all fees won't be taxed though.
You actually can't, that's a known issue, the Commerce tax logic has the following code:
// Now determine the tax amount, taking into account other adjustments.
$adjusted_total_price = $order_item->getAdjustedTotalPrice(['promotion', 'fee']);It's taking into account fees. I think there is an open Commerce issue for that (to allow determining if an adjustment should be taxable or not).
@tbkot: Instead of hardcoding the component, shouldn't we use a regular form mode? So the widget settings can be tweaked?
Shipping is taxed differently, commerce_product_tax just tells the commerce_tax module which rate it should resolve for a given product, that's all.
Patch in #8 does fix the entity definition issue, but now stores can't be disabled as the checkbox is required to save the entity.
Weird, I really remember testing that locally after writing the update hook because I suspected this would happen.
Let's go with setDefaultValue(), when I was manually checking the differences with the debugger, see the screenshot from #4. The difference seemed to be the "not null" value.
Anyway, attaching a new patch that uninstalls the content_translation_status field if present. And the update hook now only calls setDefaultValue(TRUE).
So we might need to uninstall the "content_translation_status" field.
We have this code in commerce_shipping:
$definition_update_manager = \Drupal::entityDefinitionUpdateManager();
foreach (['content_translation_created', 'content_translation_changed'] as $field_name) {
if ($field_storage_definition = $definition_update_manager->getFieldStorageDefinition($field_name, 'commerce_shipping_method')) {
$definition_update_manager->uninstallFieldStorageDefinition($field_storage_definition);
}
}
We need to do to the same I think for "content_translation_status".
\Drupal\commerce_price\CurrencyFormatter passes the locale to the Commerce Guys INTL currency formatter from the constructor:
/**
* Constructs a new CurrencyFormatter object.
*
* @param \CommerceGuys\Intl\NumberFormat\NumberFormatRepositoryInterface $number_format_repository
* The number format repository.
* @param \Drupal\commerce_price\Repository\CurrencyRepositoryInterface $currency_repository
* The currency repository.
* @param \Drupal\commerce\CurrentLocaleInterface $current_locale
* The current locale.
*/
public function __construct(NumberFormatRepositoryInterface $number_format_repository, CurrencyRepositoryInterface $currency_repository, CurrentLocaleInterface $current_locale) {
$default_options = [
'locale' => $current_locale->getLocale()->getLocaleCode(),
// Show prices as-is. All digits (storage max is 6), non-rounded.
'maximum_fraction_digits' => 6,
'rounding_mode' => 'none',
];
parent::__construct($number_format_repository, $currency_repository, $default_options);
}
You should double check what is your current locale.
Also, you could potentially swap the CurrencyFormatter with your own and hardcode the passed locale to the desired one.
Support requests aren't answered from Drupal.org per the issue queue guidelines. Also, this is related to one of your custom fields so we cannot really provide assistance here.
Since this is likely due to your custom setup, it is hard for us to provide support here. Also, it has been more than 4 years, so I'm guessing this is no longer relevant. Feel free to reopen in case you're able to provide reproducible steps and more information about the bug.
I know this has been created a while ago... Are you invoking capturePayment() yourself? If so, entities are always passed by reference in PHP, so the original payment entity passed to capturePayment() should reflect the changes after its invoked no? Also yeah, because of BC, we can't really change this.
I just tried that and couldn't apply the same coupon code more than once.
Anything particular about your setup? Or was this fixed since this was reported?
Considering this as outdated since there hasn't been a new report since october 2022. Also, a bug that cannot be consistently reproduced is very hard to fix.
I believe this is a duplicate of 🐛 Skip Order Refresh on draft anonymous orders on CLI Fixed .
jsacksick → changed the visibility of the branch 3326441-paymentmethodpermissionprovider-error-in to hidden.
hm... Could you provide an extended backtrace? This should help identifying what's causing this. Right now it is hard to assist with such little information.
Hm... I'm not experiencing this... Is this happening on a vanilla install? If so, could you provide reproducible steps and reopen?
Closing this as I'm not really sure what was actually reported and there was no response to my comment from 2023.
Ok so I asked ChatGPT which says the following :):
So why are you getting /product/123;?v=12346;?
👉 It’s most likely due to trailing commas in the replaceState call:
window.history.replaceState(
{},
document.title,
`${window.location.pathname}?${params.toString()}`, // <-- this comma
);In JavaScript, trailing commas in function arguments are allowed in modern engines, but some minifiers, transpilers, or older browsers can mis-handle them. If that happens, the argument list can be parsed incorrectly, and you can get garbage like ; injected into the resulting URL string.
Going to remove the comma and commit, hoping we finally identified what's causing the issue.
What is your suggested fix? Likely not a "bug" but more like a documentation issue? Or perhaps we should not hide the order types if there is only one? Or not make it required if there's a single order type?
I believe this was addressed by 📌 Add Adjustment Total Field Formatter Active .
This is more like a support request which aren't answered from this queue per the issue queue guidelines.
With that said, you should be able to extend the core login checkout pane programatically and override the isVisible() method to account for your custom logic.
I'm going to mark this as "won't fix" as we're trying to move away from the IEF module (which still doesn't have a stable release).
We're getting closer to that thanks to the new order items widget introduced in 📌 Define an OrderItems widget leveraging our Inline Form plugins Active .
Yes, definitely a core issue, marking this as won't fix as we can't actually do anything about that.
There are templates you're free to alter based on the price formatter used.
This would be more like a support request which aren't answered from this queue.
I also don't think we could provide a quick answer here, as this would require knowledge of your setup etc.
hm... This isn't a bug, this is the default checkout completion message which can easily be changed by changing the checkout pane settings.
Likely too late to change this... Would be to afraid to break existing sites relying on the current behavior somehow.
This is likely outdated and may have to do with your setup. Not so much we can do from the Commerce side of things as this cannot be reproduced on a clean install.
Should we not extend the title widget instead? Add settings to be able to choose a different field rather than defining a completely new widget that duplicates most of the existing logic?
This is likely due to custom code or a contrib code perhaps? If this was a widespread issue, we would have gotten more similar reports. Besides this report is probably outdated by now.
You have several ways of extending this. EIther by swapping the Inline form plugin, or by swapping the payment information pane and override the buildBillingProfileForm() method. Considering this hasn't been widely requested, I believe these solutions should be good enough.
Commerce 1.x supported order revisions, we actually didn't implement order revisions due to the numerous issues encounted with revisions back then.
Additionally, for sites with a large amount of orders, revisions are overkill and causes the DB storage to grow exponentially... So we've decided internally not to support revisions.
Hm... This isn't how it looks for me in my test install.. Also the display can be tweaked as mentioned, so not really sure there is anything actionable here.
Commerce order doesn't really do anything in particular with tokens, besides providing additional ones. Alos not sure this is still relevant after 5 years.
With the amount of information provided in the report, I'm not really able to help further. Could you provide more details? Is this still relevant after 3 years?
3 years have passed since, guessing you're not longer expecting an update. Besides, support requests aren't answered from this queue per the issue queue guidelines.
With the abundance of support available in Drupal Answers, the Drupal focused Stack Exchange site, we are no longer answering support requests in the issue queue.
Support requests opened here will be closed (won't fix), so please search for existing answers or post new questions at:
https://drupal.stackexchange.com (using the drupal-commerce tag)
Duplicate of 💬 User is sent to 403 page after successful payment (anonymous checkout) Needs work .
Just out of curiosity, why are you setting the drupal_internal__order_id? The same would happen with any other field name that doesn't exist?
What we could do instead is skipping fields that do not exist, but I think it's better to fail loudly and return an error.
I tracked down the mismatch to a schema mismatch. The status field added to the DB has a NULL default value but somehow it should have been set as "NOT NULL":
I don't really know what is causing this but we should be able to fix this with another update hook.
I would have imagined the field should have been updated during the updates but appears it was not.
The field is installed from the hook_install(), so I believed it was installed, the mismatch could be due to anything, I'll look into it.
Let me just ask "Why would you add a boolean to mark something as enabled, when by default it was already enabled?
We're using the EntityPublishedInterface and EntityPublishedTrait provided by core allowing us to leverage all the built-in Drupal core logic around access handling etc... So we aren't really reinventing the wheel here.
Also FYI, most of the time the mismatched error reported is inconsequential.
Then you don't have to worry about updating x-number of entities that were already enabled and active by default
Unless you have millions of stores, this should be pretty fast as we aren't loading / saving entities etc... The initial value is set via a direct SQL query.
Because the following code:
$percentage = $rate->getPercentage($calculation_date);
Can in theory return NULL and we aren't accounting for that.
Removing the rate completely might not be a good idea either.
I just wonder what would happen if people assign the "intermediate" VAT rate now. Will orders get "no rate"?
But it seems the right thing to do according to https://www.avalara.com/vatlive/en/country-guides/europe/romania/romania... as well.
Merged, probably would have made sense to expand the tests for this, but wasn't sure where...
I opened an MR with the change from #11, not sure which test should we update to test for this... But let's see if the current tests are green.
Did you double check that was truly the case? D10 had a fallback for NULL placeholders but D11 hasn't. Even without the fallback, I believe the error would read different, so not 100% sure what is happening, would be great if you could confirm to be on the safe side.
So perhaps we should just remove the "Default" policy, and skip the order type signature change (haven't looked at the suggested approach for the alternative suggested approach).
But I think the extra interface / trait doesn't make sense once again unless it is reusable by other entity types.
I see the benefit of the trait / interface if the methods / code is reusable. It is not the case here. I think the trait + interface would make sense in case we come up with code that is generic enough to be reused by other entity types or emails (such as the shipment confirmation for example, or if we extend it to any kind of order communication).
Otherwise, I really don't see the benefit of the interface if the only entity implementing it is the order?
jsacksick → created an issue.