All images disappeared when jetpack site accelerator is enabled! (Core Server)

update Last updated: August 13, 2022 at 10:22 PM

There is a big fuss about corona in the streets, but I had 😱 a hard time with the failure of website maintenance the other day

I was going to write an article other than IT after a long time, because it was too bad, i'll leave the history of the thing as a memorandum.

When I raised WordPress to the latest version 5.3.2 and was writing an article in the block editor "Gutenberg", in order to check the operation of the new function "Tile Gallery" of Jetpack, I enabled "Site Accelerator (formerly Photon)" in the settings of the WordPress plugin "Jetpack", and suddenly, All images on this website are no longer 💦 displayed.

Originally, Jetpack "Photon", fancyBox and other image processing system plug-ins and i knew that the problem would occur, but I was very aware that should not be used, Jetpack's "speed up the loading of site accelerators / images" with a light feeling of just testing a little was a long time of luck.

To use "Tile Gallery" in the block editor, this setting is the premise, but from the conclusion,The Tile Gallery in the Block Editor is not available. Never enable site accelerators in Jetpack settingsIt is that.

In fact, on other test servers, jetpack site accelerator is displayed properly even if you enable the image, but in the environment of the coa server it seems to be related to the security settings of the server, It seems that cdn_content delivery network_is not working effectively.
This site accelerator is a service that wordpress servers take the place of the server of WordPress to display data such as images of posts and pages, eye-catching images, and post thumbnails. This has the advantage of reducing the load and transfer volume of the server that you operate, but there seems to be no benefit to the cost unlimited coor server.
In addition, jetpack CDN, image quality is compressed because the image is lowered, the following restrictions have been announced, it will be all the more depressed.

Cache is not disabled – currently, the image is cached "permanently" and the static asset is associated with the published version of WordPress, Jetpack, and WooCommerce. For images, you will need to rename the file when you "reload" the image. Adding random query arguments is a very common cache removal method, but it is not available here.
If you have any images you would like to erase, please let us know. WordPress.com will clear the image if you provide a direct link to the image file that appears on the site. Direct link for image files is a link that begins with i0.wp.com, i1.wp.com, i2.wp.com or i3.wp.com.


Based on the above, when "Site Accelerator" was turned off in the jetpack settings, the following error is displayed, it is no longer possible to turn off. This seems to be a phenomenon that only happens to the core server.

設定の更新中にエラーが発生しました (無効なパラメーター: photon (Status 400))。


2020.04.23 Postscript
We investigated the Jetpack support forum for the HTTP400 error above, and it seems that the server-side security settings have limited ip address from overseas. In addition, it is confirmed that it is not within the IP address limit of our ".htaccess".

I had no choice but to restore the database, and once the image was displayed, jetpack was still set up.
Apparently this setting seemed to be left to the WordPress side.
Then, when I examined it on the net, I found that there is a hidden page of Jetpack settings in the url below, where cdn-related settings were safely disabled.

/wp-admin/admin.php?page=jetpack_modules

So, i was relieved for a while, but it may have been a disaster to reinstall jetpack in confusion, this time the following error occurs, Jetpack and WordPress can no longer work together.

This was also examined, it was resolved by removing the RPC rejection setting described in the following ".htaccess".
In the first place, the plug-in "Disable XML-RPC Pingback" because i have installed , this description may not have been necessary.

# Denial xmlrpc.php
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>


Here, once, after disabling and re-activating the plug-in "Jetpack", we succeeded in working with WordPress, and now jetpack of Onimon "Site Accelerator" was able to turn off. Of course, the image is now displayed properly.

2020.04.12 Postscript
The following description has been added to the ".htaccess" settings to avoid pingback attacks from BOTs other than Jetpack. At the same time, I've diasbled the plugin "Disable XML-RPC Pingback" and uninstalled.

# XML-RPC にアクセス制限、Automattic(Jetpack)は許可
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
# Automattic を許可
Allow from 54.217.201.243
Allow from 54.232.116.4
Allow from 122.248.245.244
Allow from 192.0.64.0/18
</Files>
# END XML-RPC にアクセス制限、Automattic(Jetpack)は許可


2020.04.12 Postscript
As a memorandum of Jetpack's many troubles, I've described Jetpack's evaluation in the following WordPress Jetpack plugin support forum.

🔗 Too much trouble

All of the above are in English, and the Japanese language is also included below.

Support » Plugin: Jetpack by WordPress.com » Too much trouble

Too much trouble
★☆ ☆ ☆ ☆ ☆ ☆

The following is the trouble content.

1. Site Accelerator Problems
I had trouble enabling jetpack's site accelerator and all the images disappeared. This is because there are servers that do not support CDN due to differences, such as rental server security settings. In fact one of the servers I operate did not work.

In addition, Jetpack CDN, because once the cache of registered image data will never be able to be changed again, this feature is too scary to use.

2. Xml-RPC Pingback cannot be disabled
To use this plug-in, you must enable "XML-RPC Pingback", which is a security issue, and you cannot install it, and by enabling it, it causes anxiety about future security.

Unavoidably, in order to avoid pinback attacks from BOTS other than Jetpack, we have added the following descriptions in ".htaccess". (2020.04.20 update)

# Restrict access to XML-RPC, Allow Automattic (Jetpack)
<Files xmlrpc.php>
Order Deny, Allow
Deny from all
# Allow Automattic
allow from 66.135.48.128/25
allow from 66.155.8.0/22
allow from 66.155.38.0/24
allow from 69.174.248.128/25
allow from 72.233.119.192/26
allow from 76.74.248.128/25
allow from 76.74.254.0/25
allow from 76.74.255.0/25
allow from 185.64.140.0/22
allow from 192.0.64.0/18
allow from 198.181.116.0/22
allow from 192.0.64.0/255.0.64.0
allow from 207.198.101.0/25
allow from 207.198.112.0/23
allow from 209.15.21.0/24
allow from 216.151.209.64/26
allow from 216.151.210.0/25
</ Files>
# END Restrict access to XML-RPC, Allow Automattic (Jetpack)

2020.09.28 UPDATE
Automatic's IP address may change in the future, so we are currently removing the above definition.
Also, considering the ongoing operation of Jetpack, XML-RPC Pingback is now running with XML-RPC Pingback enabled because it is not troublesome to enable it at all times.


3. Despite the state in which the connection between Jetpack and WordPress is established, when you run the WordPress site health check, the following fatal error that the connection between Jetpack and WordPress is disconnected is indicated.

“My site name Not connected. : 200” is displayed.

This event does not occur on the unencrypted (http:) of my website, but only confirms it on the encryption (https:) site.

4. Summary
To use Jetpack's Tile Gallery in Gutenberg, you must enable the Jetpack Site Accelerator. Therefore, depending on the server environment, this feature is not available, and for that much, we should not enable such a horrible feature.

Jetpack has dramatically increased the risk of competing with other plug-ins as many features are offered, and I think it is a strong plug-in.

Currently, in order to work jetpack properly, or stop other plug-ins, or reinstall and reactivate Jerpack, i have asked the user a lot of effort, i think this is not a decent plug-in.

For now, for me, jetpack only needs subscriptions and RSS features. Other Jetpack features are not required because they can be covered by other plug-ins.

By the way, when you install Jetpack, subscriptions and RSS features are treated as optional and are not available unless you add them from the Jetpack module menu. The fact that only unnecessary features are included in the standard menu is puzzling.

I wrote a lot of complaints, so as not to get in the way of other plug-ins in the future, I want you to improve aimating at a simpler plug-in.


2020.04.18 Postscript
A new version (8.4.2) to deal with Jetpack's 200 errors was released on April 14, so we immediately updated the Jetpack plug-in.
However, the following error appeared on the Jetpack settings screen this time and it did not go any further at all.

Unable to insert blog. Please try again or contact support.

I disabled all plug-ins, uninstalled and reinstalled Jetpack, and still got the same error.

I contacted the Jetpack Support Forum and the engineer in charge of Automatic, which operates Jetpack, and we finally solved this issue, as described in the link to the forum below.
This seems to have been a problem on the server side of the Jetpack.
By the way, the error is no longer displayed in the site health status.

🔗 An error occurs in Jetpack 8.4.2 and I cannot set it!



2021.06.21 Added
We reported jetpack bug to the WordPress forum below.
The main bugs are that the CDN does not work when jetpack site accelerator is enabled, the image does not appear, and if you enable comments in jetpack discussion settings, the comment section will be broken.
Perhaps the cause is that security controls on the core server limit ip addresses sent and received from Automattic.
Since the access restriction of the core server seems to be done automatically, the fundamental solution is difficult, and it seems impossible to use all the functions of Jetpack in the core server.


The following is an answer from Core Server Support:

Thank you for your continued patronage of our services.
We will inform you about the inquiry.

When I confirmed it with our department, some IP addresses were rejected on the server side of our company within the IP address range of "192.0.64.0/18" contacted and connection restrictions were implemented.

The above restrictions have been lifted by the department in charge.

However, we have a security mechanism that automatically rejects the source IP address that is causing the high load on the server.

Therefore, we may refuse to connect from the target IP address again, but please understand that we can not stop implementing the above restrictions for security reasons.

If you have any other questions, please feel free to contact us.
We look forward to your continued service in the future.

Customer Support Questionnaire - Value Domain -
https://forms.gle/ALokqBu4ws9e4v4Z6


2021.06.24 Update
Yesterday, the following contact was made by the hosting company, Bear Server, as follows:

The correspondence that we have implemented this time is to cancel all restrictions by IP address, such as restrictions on the connection source IP address of the behavior suspected brute force attack on WordPress.

Customer Support Questionnaire - Value Domain -
https://forms.gle/ALokqBu4ws9e4v4Z6


Therefore, we checked the operation of Jetpack.
As a result, we have confirmed that the following bugs have been resolved for the core server:

  1. Jetpack extension on/off causes "Status 400" error
  2. Site Accelerator (CDN) not working

Therefore, I will close this topic.
I would like to express my gratitude to those who cooperated in this survey.
Thank you very much for this time.

Add this entry to the hasebookmark
X (post)

Leave a Reply