@josephr5000

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.