Neither $status nor $payment_gateway are used in the function sop it is safe to simply remove them.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
It seems to be a common Commerce issue, see Cannot remove conditions if you remove required field values first 🐛 Cannot remove conditions if you remove required field values first Fixed .
Apparently the fix not always works as expected.
alex.bukach → created an issue.
alex.bukach → created an issue.
Agree @vidorado, the proper fix is to find the formatter(s) that return NULL and fix them.
This issue comes down to this Drupal 6 Views commit d3e13925.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
@berdir, do you still think your solution in #8 will not work?
Why should not we store the result of isMultilingual() like this?
alex.bukach → created an issue.
Good point, thanks @smustgrave, I have also created a MR!137 against 7.0.x. The patch in #27 works for both 6.x and 7.x.
alex.bukach → changed the visibility of the branch 3396769-resource-not-found-7 to active.
alex.bukach → changed the visibility of the branch 3396769-resource-not-found-7 to hidden.
The patch #12 does not work on pages with invalid route parameters, e.g. /node/[nid] for a non-existent node ID. Here's an updated patch (the PR !86 is updated respectively).
alex.bukach → created an issue.
Thanks @jim_b, I faced the same issue, and the workaround worked for me.
alex.bukach → created an issue.
Re-rolled #6 for 4.0.0-alpha6.
alex.bukach → created an issue.
@ptmkenny no, it does not look like you addressed in 2.x so it remains relevant. I rebased your MR against the head of 2.x.
alex.bukach → made their first commit to this issue’s fork.
As the patch #8 is not applicable anymore, I created a MR !11 with the same fix.
The MR pipeline fails due to unrelated issues.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
alex.bukach → created an issue.
I tried MR !15, and a webform submission (an AJAX request) is sent earlier than reCaptcha token is received and populated. It looks like AJAX form submissions are not prevented for AJAX forms.
MR !4 fixes the issue.
alex.bukach → created an issue.
Re-rolled the patch.
In our case it was EU Cookie Compliance → module that loaded the Leaflet module scripts without the dependency.
@hannakras I suggest you to have a look at https://www.drupal.org/project/countdown/issues/796110 🐛 Day is cached Needs review and the MR there. I ended up reworking the whole module.
Provided patch for 8.x-1.24 based on MR!142.
alex bukach → made their first commit to this issue’s fork.
Re-rolled the patch #29 against head of 8.x-4.x, and opened corresponding merge request !6.
alex bukach → made their first commit to this issue’s fork.
alex bukach → made their first commit to this issue’s fork.
I have reworked the module to use JavaScript for counting so that the blocks can now be safely cached.
I confirm the module does not work as expected, I can see that issue in both 7.x and 8.x versions. The JavaScript code expects the numbers be wrapped in 's, however they are not. Fixing it was a part of a @burt.lo's patch in #2. Here's a 8.x patch.
alex bukach → created an issue.
Rerolled the patch #18 against 10.3.
Re-rolled #32 for 10.3.1.
Alex Bukach → made their first commit to this issue’s fork.
Alex Bukach → created an issue.
Patch #221 seems to work fine for me, however I face the issue mentioned in #236 too. Here's an updated patch.
Alex Bukach → created an issue.
Created MR!86, here's the respective patch.
Alex Bukach → made their first commit to this issue’s fork.
@cchoe1 @Seth H, isn't it a duplicate of https://www.drupal.org/node/3266382 → (where @cchoe1 provided a similar patch)?
Are you sure the issue happens only because a payment method is treated as reusable?
Re-rolled the patch against the head of 8.x-1.x and created respective MR!102.
Re-rolled patch #7 against the head of 8.x.1-x and created MR!101.
Alex Bukach → changed the visibility of the branch 3266382-register-after-checkout to active.
Alex Bukach → changed the visibility of the branch 3266382-register-after-checkout to hidden.
Rerolled the MR against the head of 8.x-1.x.
Alex Bukach → made their first commit to this issue’s fork.
Updated the patch based on the MR!100.
Re-rolled.
Here you are @smustgrave!
Here's the correct patch.
@DanielVeza I am still able to reproduce it on a fresh Drupal 11 setup. Here are the steps:
- Navigate to a page /node/[nid]/layout?destination=[destination].
- Click "Discard changes".
- Get redirected to the [destination] page instead of /node/[nid]/layout/discard-changes
Here's an updated patch.
Alex Bukach → created an issue.
The MR 18 fixes the issue.
@jsacksick, at currently our project uses only fields declared Commerce API's, so we can rework the code to uninstall it. However I believe Commerce API should not break commerce shipping functionality anyway. I have found other scenarios when shipping address is empty, and the attached patch does not fix them. Therefore I dig further and came to another solution I posted in an issue for Commerce API 🐛 Empty shipping address Needs review . Therefore I am closing this issue.
I have checked that skipping saving profile for computed fields resolves the issue. However as all order profile fields declared by the module are computed fields, it's not clear why do we need to save the profile there anyway.
Alex Bukach → created an issue.
@jsacksick sorry again, it is Commerce API that provides the base field, we do use it as well, and I am checking whether we still need it :)
Sorry, my fault @jsacksick, I have updated the issue description.
I understand it might be not the best solution, however it's ShippingInformation pane that saves a shipping profile and then almost immediately saves a related order which in the case contains the shipping profile as well (though stale), and I cannot see any other way to hook into the process.
The same solution was suggested in the " OrderVersionMismatchException caused by ShippingInformation.php unnecessarily saving the order → ", however there were able to find more elegant solution. Can you see another way to fix it in the case?