MR added. Here's a patch for convenience.
josephr5000@yahoo.com → created an issue.
Here's a fix.
josephr5000@yahoo.com → created an issue.
@anybody my apologies, I missed your request from June. Thank you for committing my fix.
Simpler fix.
I've seen a few bug reports like this where the fix has been to make the antibot_key scrambling more elaborate.
I wonder: is it known why the existing input[name="form_token"] XSRF token doesn't accomplish the needed anti-forgery goal? Excuse me if this is a dumb question. Given the energy invested in rolling a separate antibot_key I assume there is a reason, but am not sure what is the reason.
I've seen a few bug reports where the fix has been to make the antibot_key scrambling more elaborate.
I wonder: is it known why the existing input[name="form_token"] XSRF token doesn't accomplish the needed anti-forgery goal? Excuse me if this is a dumb question.
Revised patch with style changes to match MR 137.
Excuse the noise. I noticed my first MR 136 lacked diffs. MR 137 fixes that.
Ready for review!
Patch file to match the merge request.
josephr5000@yahoo.com → created an issue.
Adding a patch to snapshot current changes in MR19 so I can refer to it in my composer.json.
josephr5000@yahoo.com → created an issue.
Worked for us too. Recommend this be merged into the main branch.
Giving this another RTBC. And no, I've no idea how many RTBCs an issue needs :-)
Uploading the change in #2 as a patch so it's more easily usable while we wait for the maintainer to merge this.
Re the question in #6 above:
All events generated by facebook_pixel or facebook_pixel_commerce are funnelled through facebook_pixel_page_attachments() which runs Xss::filter(json_encode($event['data']) on the event data.
I think it is therefore a safe assumption that once you get to the client-side javascript where initTracking() loops over drupalSettings.facebook_pixel.events, that events['data'] will be JSON-encoded, so doing JSON.parse() is appropriate without needing to check if events['data'] is already an object.
Changing status to "needs review" since there is now an active merge request.
Here's a patch for the MR !19 change from #2 above
josephr5000 → created an issue.
Changes:
- I recovered @SocialNicheGuru's change
- Created a merge request from the issue fork
- Attached patch #68 for your convenience
Advance apologies that my branch name might not have been the best choice. If anyone wants to rename it, feel free.
josephr5000 → changed the visibility of the branch 3172234-allow-to-retry to hidden.
josephr5000 → changed the visibility of the branch 3172234-patch-60-plus to hidden.
josephr5000 → changed the visibility of the branch 3172234-patch-66 to hidden.
Patch 66 changes the payment retry route, but for a transitional period there may be Dunning emails in customer inboxes that still point to the old (deprecated) route. Here's a utility module I'm using to bridge the gap, in case anyone else finds it helpful.
The initial route has a /user/{user} prefix whereas subsequent routes in the checkout flow lack that. This makes it harder than necessary to theme for consistent and trustworthy UX appearance throughout this flow. It seems preferable to work with the order's customer instead of obtaining the $user from the route, making it unnecessary to have the /user/{user} prefix.
I'd appreciate others checking to be sure you agree that working with the order's customer is a valid thing to do here!
This patch removes the /user/{user} route prefix and makes some consequential adjustments.
NOTE: this patch is based on #60 as I couldn't get #64 to apply cleanly to 8.x-1.x-dev. Happy to re-roll if @SocialNicheGuru can help me out.
josephr5000 → made their first commit to this issue’s fork.