Bereshka

I followed these instructions and it worked for me.

Once you do that, please follow these steps:

1. Go to “Other options” section
2. Change backup method: https://prnt.sc/1s1ofpa
3. Disable PHP CLI checking: https://prnt.sc/1sljr31
4. Save “Other options” section
5. Force stop both processes: https://prnt.sc/1trv1tm

When you do that, try to run your backup once again.

Let me know if that worked for you?
Thank you!

I found solution, I just get to the files of the blog through ftp and disabled JetPack, then I reset a password in MySql, and I was able to login, then I activated JetPack and everything is working fine.

how would be nice if you share how u fixed it

Hello,

Thanks for your update.

I understand that you are now able to access your images via HTTPS and not getting the error. However, ‘tools.pingdom.com’ still recommends you to parallelize downloads across hostnames.

The Parallelize Downloads Across Hostnames warning is an optimization recommendation previously suggested by many popular speed test tools such as Pingdom, GTmetrix, PageSpeed Insights, and more. This warning is becoming less and less important as more website owners move to HTTP/2. HTTP/2 allows multiple resources to be loaded in parallel using only one connection. However, for those still using HTTP1.1 and loading multiple resources, it can be beneficial to implement what’s called domain sharding [1].

The reason you are seeing this warning is that web browsers are limited to the number of concurrent connections they can make to a host. This is mainly due do HTTP/1.1 in which browsers open on average 6 connections per hostname. This warning is typically seen on websites with a large number of requests. In the past, the only way to get around this limitation is to implement domain sharding.

However, if you are running your website over HTTPS with a provider that supports HTTP/2, this warning can usually be safely ignored now. With HTTP/2 multiple resources can now be loaded in parallel over a single connection. Over 77% of browsers now support HTTP/2 when running over HTTPS, as well as many CDN including CloudFront [2]. As per this [3] document, it is important to note that Pingdom doesn’t support HTTP/2 yet since it uses an older version of Chrome.

Please refer these [3][4][5] documents for more details.

As you are serving your website over HTTPS, you can safely ignore this warning as CloudFront and modern browsers supports HTTP/2.

================

References:

[1] Domain Sharding: https://blog.stackpath.com/glossary/domain-sharding/
[2] Amazon CloudFront now supports HTTP/2: https://aws.amazon.com/about-aws/whats-new/2016/09/amazon-cloudfront-now-supports-http2/
[3] How to Fix “Parallelize Downloads Across Hostnames” Warning: https://kinsta.com/knowledgebase/parallelize-downloads-across-hostnames/
[4] Parallelize downloads across hostnames: https://gtmetrix.com/parallelize-downloads-across-hostnames.html
[5] How To Parallelize Downloads Across Hostnames: https://www.keycdn.com/support/parallelize-downloads-across-hostnames/

I hope the above information was helpful to you. Please do not hesitate

Best regards,

Ritish G.
Amazon Web Services

Hello, Ritish,
Your answer is very helpful, I did all what you recommended below, as I use free certificate and my hosting provider refused to provide the certificate body, I just requested here another certificate, verified through DNS and everything is working. tools.pingdom.com still recommends me to parallelize downloads across hostnames, some were, but some not. But i guess or I should wait more time or investigate why it doesn’t parallelize all

Hello, Carlos,
Let me hang here my conversation with Amazon TechSupport, I think it might be useful

Hello,

Thank you for contacting AWS Support. My name is Ritish and I’ll be assisting you today.

I understand that you are seeing an ‘err_cert_common_name’ error while accessing your images using the CNAME added to your CloudFront distribution. Please correct me if I am wrong.

I checked using my internal tools and was unable to found the CloudFront distribution with the domain name ‘d1hvnfrkakoqfp.cloudfront.net’. It seems like you have deleted the previous CloudFront distribution and created a new one with the domain name ‘d3gejou8t706cm.cloudfront.net’. I can see that you have added 3 CNAMEs on this distribution which are: c3.usrussiacc.org, c2.usrussiacc.org, c1.usrussiacc.org. Please confirm if this is the desired distribution.

I tried to access the image using the URL: ‘https://c1.usrussiacc.org/wp-content/uploads/2018/01/1347.jpg’ and was also getting the same error ‘ERR_CERT_COMMON_NAME_INVALID’.

The reason you are getting this error is that you are currently using default SSL Certificate on your CloudFront distribution which only allows ‘*.cloudfront.net’ domains to make a request to your distribution. This is the reason I was able to get the image using the CloudFront domain URL: ‘https://d3gejou8t706cm.cloudfront.net/wp-content/uploads/2018/01/1347.jpg’.

In order to resolve this issue, I request you to add custom SSL certificate to your CloudFront distribution and include all the domains in this certificate using which you will access your CloudFront distribution such as (c3.usrussiacc.org, c2.usrussiacc.org, c1.usrussiacc.org). You can also use a wildcard in your domain name at sub-level eg. *.usrussiacc.org in your certificate domains.

You can use AWS Certificate Manager service to create custom SSL certificate for your domain. Public SSL/TLS certificates provisioned through AWS Certificate Manager are free. You pay only for the AWS resources you create to run your application.

Please follow the steps below to create a certificate and update your distribution to use this custom SSL certificate:

1. Request a Public Certificate: I request you to please refer this [1] document which contains detailed steps to request a public certificate using the console. However, please ensure that you are requesting the certificate in the N. Virginia (us-east-1) region using the AWS Console URL (https://console.aws.amazon.com/acm/home?region=us-east-1#/)

2. Once your certificate is validated and the status is changed to ‘Issued’, you can add that certificate to your distribution.

3. Select your CloudFront distribution.

4. On the ‘General’ tab, click on ‘Edit’.

5. Under SSL certificate option, select ‘Custom SSL Certificate (example.com):’

6. From the drop-down list select the certificate created in Step 1.

7. Click on ‘Yes, Edit’.

Once you successfully made the above changes and your configuration is deployed across all the CloudFront edge location and the ‘Distribution Status’ is changed to ‘Deployed’, you can access your images using the URL: ‘https://c1.usrussiacc.org/wp-content/uploads/2018/01/1347.jpg’.

However, if you still face the same issue, I request you to please share the HAR File. Please note that the HAR capture must be started before making any request. Please refer the following document for more details on generating HAR file: https://toolbox.googleapps.com/apps/har_analyzer/

================

References:

[1] Request a Public Certificate: https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html#request-public-console

I hope the above information was helpful to you. Please feel free to get back to us if you face any issue with the information provided above or for any further queries. I would be more than happy to assist you.

Best regards,

Ritish G.
Amazon Web Services

I found solution. If your website has SSL certificate, then you need or to import your SSL certificate to Amazon Cloudfront and then to link it to your distribution, or if you have free SSL certificate, that my hosting didn’t wanted me to provide the body of it, so I couldn’t import, then just request certificate at the admipanel of Cloudfront, SSL Certificates, then it will ask you to verify it through DNS, creating additional CNAME. that’s it. Images are no longer broken.

In case it may be useful to anybody, I think that I linked CDN url resource to CNAMES or CNAMES to the website too early. Means that while it’s in process and do changes through all links, including images, I should wait more. I made this conclusion because I created a new distribution and I was waiting until it changes the state from in progress to deployed. After that I created again cnames, new and pointed them to this distribution. So some of the images were shown. Anyway to see the effect of parallelize of content downloads across hostnames, I need to wait about 24 hrs. I delete all distributions and did that again and now going to wait for a day, letting it all be converted in a proper way. As it’s hard to clean the cache of CDN

• This reply was modified 6 years, 6 months ago by Bereshka.

Oh, right, how could I miss that. I see – hire developers. Good!

P.s. you r a very handsome programmer)

haha))ok, then you are a real speed optimization guru. By any chances do you take orders for that? mean can I order optimization by you?

Yes, thanks. I will do as soon as I figure out the issue.
Just using of AO by itself doesn’t give me an expected result, website is still very slow, no matter it’s loading that page or no, so can’t be sure that I will leave a good review. But it’s a free plugin, so how can I complain)) It’s a very hard task to make a one plugin like this that would work on any websites, maybe it works for very simple with few pages, but not for those that have a lot of functionality, as that minification breaks it anyway and without minification it’s slow. Vicious circle

Looks like, as I disabled all plugins that are related to the speed optimization, still same problem. Looks like smth wrong with the plugin. Thanks

I added this code to functions.php of my child-theme, no result

Hello, Thank you so much for your quick reply. I will have a shot of tequila if one day humanity will eliminate IE, it always has errors)), but unfortunately my client uses namely this browser. Other browsers looks fine.

It also has a very strange behavior

1. I can see sometimes, that homage in the morning looks like this only in IE https://www.dropbox.com/s/nub9uq1928x190a/Screen%20Shot%202018-05-22%20at%2012.50.52.png?dl=0 broken CSS. I guess it maybe somehow linked to cache size. This floating problem, when I clean cache it starts working

2. Also Revolution Slider sometimes loading with delays on the homepage in IE.

3. But the main problem with those upcoming events,I excluded calendarize.js files from JS minification, but still same problem. Let’s first solve it, maybe other will not appear again, as those 2 above problems are floating (on and off)

Shame to say, but I m looking for a solution, guys who developed this plugin Calendarize-it too and another web developer with a big experience of optimization. Nobody can fix it )

could you please share how exactly you fixed this