abonawaff53

You can mark this as resolved

• This reply was modified 3 years, 2 months ago by abonawaff53.

Hi, thanks for getting back to me.

Will do

• This reply was modified 3 years, 2 months ago by abonawaff53.

Hi,

Thanks for getting back to me.

So the address is set in my iPhone and I have always used Apple pay with no issues. I have also tried with friends phones with the same issue.

When I go to edit address on my Apple wallet, there is no “state” field when country is set to Saudi Arabia. See screenshot: https://ibb.co/T01SqR3

The API is expecting a state, but the state field is empty. This plugin should probably send the “district” as “state” instead or something.

I can’t share the system status publicly, if there is a way to do it privately, please let me know.

* The Payment Request API provides its own validation for the address form.
* For some countries, it might not provide a state field, so we need to return a more descriptive
* error message, indicating that the Payment Request button is not supported for that country.

This error seems to indicate that countries that don’t return a state field aren’t supported, but SA is clearly supported and don’t return a state field.

Hi, thanks for responding.

However, Egypt was a hypothetical example.

Saudi Arabia is supported by apple pay, and when I change the store location to Saudi Arabia, the apple pay button doesn’t show up.

When I set the store location to United States for example, the apple pay button shows up for Saudi visitors but throws an error:

The Payment Request button is not supported in Saudi Arabia because some required fields couldn’t be verified. Please proceed to the checkout page and try again.
Billing State / County is a required field.
Shipping State / County is a required field.

I managed to trigger the onchange event using the following $("#fieldname1_1").trigger("change");

Somehow managed to skip my mind.

Thank you for your reply. Actually, what provokes the DIV to change its attribute is not a field within CFF but rather this function:

var _URL = window.URL || window.webkitURL;
     $("#file").change(function(e) {
         var file, img;
         if ((file = this.files[0])) {
             img = new Image();
             img.onload = function() {
                 //alert(this.width + " " + this.height);
      
                 $(".mydiv").attr({
                   mywidth: this.width,
                   myheight: this.height
                 });

             img.onerror = function() {
                 alert( "not a valid file: " + file.type);
             };
             img.src = _URL.createObjectURL(file);
         }
     });

It is basically a function that will get image dimensions before upload. I don’t need to upload the image, just get its dimensions in pixels. I then want to use the dimensions as inputs of CCF to allow users to do some calculations with them.

the div with ID #FILE is not a part CFF. I want to keep that way.

in the main function above, I can add
$('#fieldname1_1').attr('value', this.width);

This will change the value of the field, but dependent calculated fields will not reevaluate and I will have to click on the field and then press Enter for the onchange event to trigger.

Any idea how to proceed ?

• This reply was modified 3 years, 4 months ago by abonawaff53.
• This reply was modified 3 years, 4 months ago by abonawaff53.

Hi,

Thanks for getting back to me.

Yeah I know that. Still need to block them anyways.

There is not a single reason why would any legitimate user visit our site from behind a TOR exit node. I doubt an oppressed Chinese journalist will have the time to be on our site shopping for “colorful shoe laces”.

We already enabled the RECAPTCHA on all forums. However, there are still a lot of visits from those IPs and they should all be BLOCKED. They are not legitimate visitors and allowing them to add extra unnecessary load on the server is not optimal. Let alone the fact that those visits skew our Analytics data and spending the time trying to isolate them from the data will just cause more unnecessary headache.

You guys should add the option to block IPs in bulk.

Hi,

Thank a lot. You were correct. I just noticed that I was checking on a product page by woocommerce. Any idea as to why is woocoomerce loading these two particular scripts?

BTW, both scripts are within in wordpress core files at wp-includes and not inside woocommerce files. Thats why I didn’t suspect woocommerce.

you can see more about the issue here: https://github.com/ytdl-org/youtube-dl/issues/21729

Hi Ahmed,

Thanks for trying to help.

Here is my take on the issue. WordPress uses IPV6 connection and your own server IP to make connections to youtube servers. This happens with embedded videos only. I don’t know why this happens.

When you paste the url through PHP, it will work because either:
1- Connection uses user’s IP which is not blocked by youtube.
2- Connection uses your IPV4 which is not blocked by youtube.

So, what YouTube really blocks is a range of IPV6 that belongs to your hosting provider and your own server IPV6 happens to be within that range. Why does youtube do this ? I don’t know.

Possible solutions:
1- Completely disable IPV6 on your server. This will force all connections to go through IPV4 which is not blocked.
2- Find a way to force wordpress to connect to youtube using IPV4 only instead of completely disabling IPV6.
3- Find a way to make embedded youtube videos use visitor’s IP and not your server IP.

BTW, a lot of hosting providers seem to be affected by this. I know DigitalOcean and CloudWays and few others are.

• This reply was modified 4 years, 10 months ago by abonawaff53.

Hi,

So I managed to pin point the issue. Youtube is blocking a range of DigitalOcean ipv6.

Disabling ipv6 on our droplet fix the issue. Apparently YouTube is only blocking their ipv6 and not ipv4 for one reason or another. I only disabled ipv6 entirely because I don’t know how to force embedded videos to requests to connect on ipv4 instead of ipv6.

After notifying DigitalOcean about this, their support are suggesting that we keep redeploying with different IPs till we magically find one that is not banned!

Hi Ahmed,

The thing is, we keep getting banned / unbanned. So, one hour videos will be working, and the next they stop, then an hour later the ban gets lifted, and they start working again and so on.

I just can’t figure out whats making so many connections to youtube network to upset them ??

Hi Ahmed,

thanks a lot for getting back to me.

As you suggested, the issue seems to be YouTube temporary bans our IP for “unusual traffic”.

I tried doing curl https://www.youtube.com/watch?v=oZnhxJwL_PU and sure enough the request didn’t go thro. This is the message returned: Our systems have detected unusual traffic from your computer network. Please try your request again later”.

I am now positive that youtube is blocking our IP. I have Contacted DigitalOcean and I am waiting for their response.

Since this issue is happening on two separate domains hosted on two separate virtual hosts “droplets”, I am almost positive its a hosting related issue.

I will update this once I have more info

We have 3 sites on DigitalOcean, 2 are affected by this issue. While the third site is working fine.

Whats really strange is the fact that the issue comes and goes. Like every few hours all youtube videos will start working, and then an hour later they would stop and so on.

Hi Ahmed,

I am facing the same issue, I did every thing possible to try an fix it. Would you please share how you disabled caching for wp-settings-* ?

Thanks