m22878

I tried to use the new Cache Rules configuration, disabling the Page Rule for cache everything and removing the cache buster, but it seems just as unstable as the worker mode. So I switched back on the Page Rule and simply added a Cache Rule to BYPASS all the cookies listed in the Worker, and now it seems to be working great. The page exclusions i.e. cart, checkout i.e. functionality in the plugin will still take care of those pages, right? I’m simply using the Page Rule to cache everything and then one Cache Rule which says to BYPASS the cache if any of the cookies are on the page, which includes wordpress_logged_in_ among others.

• This reply was modified 9 months, 3 weeks ago by m22878.
• This reply was modified 9 months, 3 weeks ago by m22878.

Yes, but I don’t have any of those types of extensions, meaning, if you have something in your cart, it’s literally impossible to tell unless you’re on the cart page, because there is no indication of any kind that something is in your cart via an icon in the header or a number that signifies how many items are in your cart etc.

Similarly, there is no recently viewed items etc. Nothing on the site changes based on viewing the WC store. Every user sees the exact same thing even when something is in the cart, except on the cart page or checkout pages.

Honestly, even when logged in, users see the exact same site, there is no name or anything that changes in the header or anywhere else on the site. The only real issue with caching logged in users are the comments. That is the only place where it shows a name when someone is logged in, but that’s WP posts not the WC store pages. And I have logged in users set to not cache, so that takes care of logged in commenter names from being cached.

Why is bypassing pages with Woocommerce cookies need for WC to function when you can view the entire WC store cached with no cookie so long as you don’t have something in your cart.

It seems that proves what you are saying is wrong. Only if you have dynamic content that pertains to having something in your cart like perhaps a qty box in the header, which shows how many items are in your cart, might you have to bypass WC cookies, since then users would falsely see these qty markers in their headers.

But without the cookies changing the site like that, why couldn’t you continue to view cached pages of the WC store so long as pages like /cart/, /checkout/ and /my-account/ are bypassed?

This is a really big deal as putting something in your cart basically completely disables the static HTML caching which is what makes a store so fast in the first place.

Okay, I’m finally starting to figure things out. That one response cookie that was on every page load is what confused me. I removed it now everything is working great. One question, I see you added woocommerce_ cookies to the worker to bypass the cache. Whenever you add something to you cart it slows down the entire site since it no longer serves cache. If you don’t have any dynamic content based on cart contents like in the header, can you just remove that cookie from the bypass list in the worker? I already have pages like cart and checkout bypassed. It seems unnecessary to slow the site down when I have no dynamic content related to cart items or any other WC related action, really.

How can I strip just individual cookies? I don’t want to strip them all just certain ones. I thought the ignore cookie option under worker mode was it, but I guess that’s the opposite of what I want. Apparently, when you specify a cookie there you are telling CF to not serve cache on that page with the response cookie.

Follow up, is it possible to ignore certain cookies, so that even if a particular response cookie is on a page it will still serve a static HTML page? I thought I saw that as an option under the worker settings. You can put a specific cookie name there and it will still cache any page that response cookie is on? Because I have one cookie for JetMenu that actually is a response on every page for some reason and maybe that’s why the static HTML cache isn’t being served, because I think CF doesn’t serve a static HTML page only if a response cookie is on the page but will if a request cookie is on the page.

• This reply was modified 9 months, 3 weeks ago by m22878.

We added a hook to the core code. Can you merge this upstream? This hook allows you to create security filters that will reject orders and return an error message before the payment authorization has occurred. You can rename the hook, obviously.

We created a filter so that if the 3DS doesn’t return Authenticated: Y, Liability Shift: Yes then it returns an error saying they need to try a different card, and it does this before the payment is ever authorized on their card, which is important.

With this filter, we never have to worry about chargebacks because every credit/debit transaction will have the 3DS liability shift.

View post on imgur.com

Can you explain this below in more detail? My dev doesn’t understand how to use this filter in order to bypass the authorize payment request based on the 3DS response. He seems to suggest he cannot see the 3DS response before the authorize payment request and doesn’t know how to use this filter in order to create a conditional that would bypass the authorize request based on the response of the 3DS.

If 3DS response returns anything other than authenticated: Y response we want to bypass the authorize payment request. Can you give any more direction?

There is no dedicated hook for bypassing 3DS authorization attempt but all requests could be modified through this filter: https://github.com/woocommerce/woocommerce-paypal-payments/blob/trunk/modules/ppcp-api-client/src/Endpoint/RequestTrait.php#L43

• This reply was modified 1 year ago by m22878.

Does the 3DS response come before the payment authorization attempt or after it? This is all I need to know at this point. Is there a hook I can use to bypass the authorization attempt if it comes after the 3DS response?

Right now I can void the authorization based on the 3DS response and set the order to failed status, but it would be better if I could not even do the payment authorization in the first place so that the customer could use the pay button to resubmit payment on the failed order.

Right now, since I am voiding the authorization instead of bypassing it, the customer cannot use the pay button on the failed order because the invoice number already has a voided authorization on it and you cannot reuse the invoice number through Paypal on a second authorization.

What does the void order function do? Will the order still register on the site with the status set to failed? Or something else will happen? Will the card be authorized for the order amount before this can be triggered or will this be able to void the order before the card has been authorized? I’m aware of the issue with authorization intent and 3DS data. I’ve already addressed that.

It’s because I didn’t set file permissions of the pdf and custom template dirs. Set to 755 and now it works. You should add that to the instructions for creating custom templates. Make sure to set file permissions of the pdf and template dirs.

I copy/pasted the Simple template to the woocommerce/pdf in my child theme. It has like 5 files in it I think. All I did was rename the dir. I have deactivated and reactivated plugin and it doesn’t show up under the template dropdown. It still only says Simple as the template option. No Custom option.

I had already contacted Paypal’s support and this is what they said below. Apparently, it works as intended, which is to simply trigger a 3DS attempt on every order, but if the issuing bank doesn’t support 3DS the transaction will be allowed through, anyway!

So, who wants to implement the logic that will actually reject transaction without a successful 3DS as mentioned below?

“You are correct that the SCA_ALWAYS setting is designed to trigger a 3DS attempt on every transaction, but it does not necessarily reject transactions if 3DS hasn’t been successfully completed.

The behavior you described is accurate: if the customer’s issuing bank doesn’t support 3DS, the transaction will still be allowed to go through. The SCA_ALWAYS setting ensures that 3DS is attempted whenever possible, but it does not enforce a strict requirement for 3DS to be completed for every transaction.

If you want to reject transactions where 3DS has not been successfully completed, you would need to implement custom logic in your payment processing flow. This would involve checking the 3DS status for each transaction and programmatically rejecting those without successful 3DS authentication. However, this approach may lead to false declines and negatively impact legitimate customers whose banks do not support 3DS.”

WHY haven’t they fixed this? Tracking orders is one of the main reasons anyone uses this plugin. If you cannot do this, the plugin is worthless to me.

This code does it, but is the best way to accomplish this?

(function($) {
    var fmeMasks = {
        'ev-tel': '0000-0000',
        'ev-tel-ddd': '(00) 0000-0000',
        'ev-tel-ddd9': '(00) 00000-0000',
        'ev-tel-us': '(000) 000-0000',
        'ev-cpf': '000.000.000-00',
        'ev-cnpj': '00.000.000/0000-00',
        'ev-ccard': '0000-0000-0000-0000',
        'ev-ccard-valid': '00/00',
        'ev-cep': '00000-000',
        'ev-time': '00:00:00',
        'ev-date': '00/00/0000',
        'ev-date_time': '00/00/0000 00:00:00'
    };

    function moneyMask(v) {
        v = v.replace(/\D/g, "");
        v = parseInt(v, 10);
        v = isNaN(v) ? 0 : v;
        v = v.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ",");
        return "$" + v;
    }

    $(window).on('load', function() {
        "use strict";
        $('.fme-mask-input').each(function() {
            if ($(this).data('fme-mask') !== undefined) {
                var inputMask = $(this).data("fme-mask");
                if (inputMask == 'ev-cpf' || inputMask == 'ev-cnpj') {
                    $(this).mask(fmeMasks[inputMask], {reverse: true});
                } else if (inputMask == 'ev-money') {
                    $(this).on("keyup", function() {
                        var selection = window.getSelection().toString();
                        if (selection === '') {
                            this.value = moneyMask(this.value);
                        }
                    });
                } else {
                    $(this).mask(fmeMasks[inputMask]);
                }
            }
        });
        jQuery(document).on('elementor/popup/show', () => {
            $('.fme-mask-input').each(function() {
                if ($(this).data("fme-mask") !== undefined) {
                    var inputMask = $(this).data("fme-mask");
                    if (inputMask == 'ev-cpf' || inputMask == 'ev-cnpj') {
                        $(this).mask(fmeMasks[inputMask], {reverse: true});
                    } else if (inputMask == 'ev-money') {
                        $(this).on("keyup", function() {
                            var selection = window.getSelection().toString();
                            if (selection === '') {
                                this.value = moneyMask(this.value);
                            }
                        });
                    } else {
                        $(this).mask(fmeMasks[inputMask]);
                    }
                }
            });
        });
    });
})(jQuery);