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?
@jsacksick, Commerce API is a dependency of Commerce Cart Flyout → .
Alex Bukach → created an issue.
Added patch for D10 compatibility.
Alex Bukach → created an issue.
Here's a patch to add an enhancer for the parent ID field to pass the UUID instead of just an ID.
Alex Bukach → created an issue.
Here's a patch to solve the issue.
The stripe docs state that you cannot cancel a payment intent during checkout, you must instead expire the session which isn't ideal.
That is correct only if a checkout session is used which is not the case for the module.
@RowanADev were you able to resolve the issue?
IMPORTANT: You should apply core patch from https://www.drupal.org/project/drupal/issues/3439302 ✨ Use POST to submit search block form Needs review to catch searches from search block form.
Alex Bukach → created an issue.
Relied on hook_search_preprocess() as form submit is not invoked for search block form.
Here's a patch based on the merge request !1.
As Drupal 8/9/10 version is not usable at all, I have reworked the module to have at least basic features.
The new version relies hardly on Views to display the results.
Alex Bukach → made their first commit to this issue’s fork.
Alex Bukach → created an issue.
@oktboy, the module is compatible with Drupal 10, and I cannot reproduce the issue.