Have trouble connecting Jetpack to WordPress.com? If so, here are some steps that will help you solve the problem.
Before following this troubleshooting, first check that your site is publicly available, as Jetpack will not be able to connect to it otherwise! You can learn more about why it’s necessary to have your WordPress.com account connected to Jetpack here.
Running the Jetpack Debug Tool
The Jetpack Debug Tool can identify many different causes for connection issues.
Error Messages
Seeing an error message when trying to connect Jetpack or from the Jetpack Debug Tool above?
Visit the Error Messages page to see the most common errors, their causes, and how to resolve them.
Site Health
Check your site’s health status under Tools > Site Health from the left-hand menu.
This page will run a number of different checks and provide critical information about your WordPress configuration as well as any other items that may require your attention.
Your xmlrpc.php File
Jetpack needs this file to connect to your WordPress.com account.
Start by checking example.com/xmlrpc.php (replacing “example.com” with your actual domain) in your web browser’s address bar. That page should return the following message:
XML-RPC server accepts POST requests only.
The message you see should look exactly the same, without any spaces or line breaks above or below it. Compare yours to this working example.
If you have blank lines or extra content in your xmlrpc file, you will receive an error. Please check here for fixes before you continue, and feel free to reach out to your webhost for assistance with those instructions.
Please note that your xmlrpc.php file must be in the home directory of your WordPress install. If it’s not, you can replace it by reinstalling the core files of WordPress (or asking your webhost to).
Your wp-config.php and .htaccess Files
If you or one of your plugins added code to either of these files, it may have caused a misconfiguration. You can check these guides for more information and typical settings to help revert the files back to their default state: wp-config / htaccess.
The PHP-XML Extension
The PHP on your site needs the XML extension in order to parse XML, which Jetpack needs to properly communicate with your site. Check with your webhost to make sure the PHP-XML extension is installed and active on your server.
Reinstalling and Reconnecting Jetpack
Sometimes you need to completely reset your connection between your site and our services. You can follow these instructions to accomplish that.
Cloudflare
If you are using Cloudflare on your site, check this guide to make sure Jetpack and Cloudflare are working together properly.
Plugin Conflicts
Sometimes other plugins can create a conflict with Jetpack that blocks it from connecting to WordPress.com.
To rule out a plugin conflict, deactivate all other plugins and keep Jetpack active, then try connecting again. If Jetpack connects, you can turn your plugins back on, one by one, to make sure everything keeps working.
A conflict may cause other issues in addition to not letting Jetpack connect, so check for anything else not working properly after activating each plugin. If you find that a plugin is causing a conflict with Jetpack, please reach out to that plugin’s developers to see if there is a fix to get it working with Jetpack.
Theme Issues
If you’re using a theme that’s not coded to modern standards or kept up-to-date with changes in WordPress development, then the theme could be creating issues with Jetpack’s connection or features.
Download and temporarily switch to one of the more minimal, default WordPress themes (such as Twenty Twenty Two) and see if the connection issues are resolved. If so, then you’ll need to either replace your original theme or talk to its developers to see if they can figure out where the conflict is happening and how to solve it.
Testing Your Site Speed
Your site must initially respond within 5 seconds for the Jetpack connection to work correctly.
You can check your site speed and overall performance with a variety of tools (like GTmetrix or WebPageTest) and follow up with your webhost by showing them the results. They may be able to help improve your site’s response and loading times from there.
SSL Certificates
Your SSL certificate makes sure the traffic on your site is safe and secure. Sometimes they can be misconfigured or expired, which will keep Jetpack from connecting to it. You can check for errors on your SSL certificate with this SSL Checker and test its overall health with this SSL Server Test. It should typically be graded A or A+, and you shouldn’t see any errors.
The most common SSL errors that your webhost must fix are:
- Self-signed: The certificate was not created by using standard security practices and is considered unsafe
- Missing chain/intermediate certificate: Some SSL certificates are applied to your site in multiple parts. When one or more are missing in the chain, the security becomes broken and incomplete
- Expired: Just like a domain, an SSL certificate needs to be renewed each year, or it will expire. Certificate renewals usually happen without you having to do anything, but sometimes automatic systems at your webhost may fail to do so
HTTPS Settings
Check that both the SITE_URL and HOME_URL settings under Settings > General in your wp-admin dashboard are using https before your domain rather than just http. Sites that use only http are not secure and aren’t using the SSL certificate mentioned above – https loads the certificate properly and will allow Jetpack to connect to it.
Also, make sure that all of your site’s traffic routes to https as well. For example, any requests to http://example.com should automatically redirect to https://example.com instead. Your webhost can help make sure that this happens as expected.
For more detailed information on troubleshooting SSL issues, please refer to this guide.
Server Credentials for Jetpack Backup
If you have issues adding your credentials to Jetpack Backup, we recommend contacting your webhost and asking them to provide you with this information so you can then enter it successfully into your Jetpack settings:
- Credential type (FTP, SFTP, SSH)
- Server address
- Port number
- Server username
- Server password
- WordPress full installation path
When You Should Contact Your Webhost for Support
This list of issues that must be addressed by your webhost rather than Jetpack support because they are server-related:
- SSL certificates
- Changes in IP addresses or domains/URLs
- Migration from one server to another
- Site is down or not responding
- Errors (500 / 502 / 504 / 403)
- Server resource or memory usage
- DNS problems
- Outdated server software (PHP, MySQL, etc.)
- File and folder permissions
- Problems that are still occurring even after Jetpack is uninstalled
Still need help?
Please contact support directly. We’re happy to lend a hand and answer any other questions that you may have.
We’ve finally narrowed it down to a single cause: flushing memcached. Any time we manually flush the cache, or when it’s triggered by some other action, Jetpack loses the connection.
We’ve done it three times this past week for various server and code updates, and each time the connection was broken. I’ve checked the Jetpack Debug screen and get the connection error message (XMLRPC is working fine, but JP says it can’t connect), but after reconnecting the account successfully we’re immediately back in business.
We suspect that when we flush memcached it’s also flushing the cached wp_options table, and that’s what’s causing Jetpack to go haywire. That would account for nothing in the log showing a disconnect (since a disconnect wasn’t triggered from the admin side), but doesn’t explain why Jetpack logs don’t show it being reconnected each time.
If there’s anything else we can do to test from our end we’re happy to help. In the meantime our client has asked me to investigate finding a more stable solution that doesn’t rely on the wp.com connection. :person_frowning:
Пишет данную проблему после установки самого плагина, нужно его активировать, в чем может быть проблема? Гугл не помог
Ваш сайт должен быть в открытом доступе, чтобы иметь возможность использовать Jetpack: site_inaccessible
Подробности ошибки: The Jetpack server was unable to communicate with your site [HTTP 403]. Ask your web host if they allow connections from WordPress.com. If you need further assistance, contact Jetpack Support: jetpack.me/support
-
Вопрос задан
-
15287 просмотров
Пригласить эксперта
Вот тут подробно написано почему возникает ошибка и как её исправить.
Если у Вас стоит плагин безопасности, к примеру iThemes Security, то отключаете его, потом активируете Джетпак, а потом уже включаете плагин безопасности.
-
Показать ещё
Загружается…
21 сент. 2023, в 14:51
30000 руб./за проект
21 сент. 2023, в 14:49
25000 руб./за проект
21 сент. 2023, в 14:33
5000 руб./за проект
Минуточку внимания
Have trouble connecting Jetpack to WordPress.com? If so, here are some steps that will help you solve the problem.
Before following this troubleshooting, first check that your site is publicly available, as Jetpack will not be able to connect to it otherwise! You can learn more about why it’s necessary to have your WordPress.com account connected to Jetpack here.
Running the Jetpack Debug Tool
The Jetpack Debug Tool can identify many different causes for connection issues. To verify your Jetpack connection, visit your website, copy the URL from your browser’s address bar, and paste it into the Jetpack Debug. If your connection works and all tests pass you will see the message “Everything looks great!”.
Error Messages
Seeing an error message when trying to connect Jetpack or from the Jetpack Debug Tool above?
Visit the Error Messages page to see the most common errors, their causes, and how to resolve them.
Site Health
Check your site’s health status under Tools > Site Health from the left-hand menu.
This page will run a number of different checks and provide critical information about your WordPress configuration as well as any other items that may require your attention.
Your xmlrpc.php File
Jetpack needs this file to connect to your WordPress.com account.
Start by checking example.com/xmlrpc.php (replacing “example.com” with your actual domain) in your web browser’s address bar. That page should return the following message:
XML-RPC server accepts POST requests only.
The message you see should look exactly the same, without any spaces or line breaks above or below it. Compare yours to this working example.
If you have blank lines or extra content in your xmlrpc file, you will receive an error. Please check here for fixes before you continue, and feel free to reach out to your webhost for assistance with those instructions.
Please note that your xmlrpc.php file must be in the home directory of your WordPress install. If it’s not, you can replace it by reinstalling the core files of WordPress (or asking your webhost to).
Your wp-config.php and .htaccess Files
If you or one of your plugins added code to either of these files, it may have caused a misconfiguration. You can check these guides for more information and typical settings to help revert the files back to their default state: wp-config / htaccess.
The PHP-XML Extension
The PHP on your site needs the XML extension in order to parse XML, which Jetpack needs to properly communicate with your site. Check with your webhost to make sure the PHP-XML extension is installed and active on your server.
The JSON API (REST API)
Jetpack uses XML-RPC and the JSON API (REST API) to communicate with your site. Please ensure that the JSON API is enabled on your site and that authentication is disabled. If you would prefer not to disable authentication on the JSON API for your site, please allowlist the /jetpack/v4/ and /wpcom/v2/ namespaces instead. If you’re not sure how to do this, please contact your host for help.
Reinstalling and Reconnecting Jetpack
Sometimes you need to completely reset your connection between your site and our services. You can follow these instructions to accomplish that.
Cloudflare
If you are using Cloudflare on your site, check this guide to make sure Jetpack and Cloudflare are working together properly.
Plugin Conflicts
Sometimes other plugins can create a conflict with Jetpack that blocks it from connecting to WordPress.com.
To rule out a plugin conflict, deactivate all other plugins and keep Jetpack active, then try connecting again. If Jetpack connects, you can turn your plugins back on, one by one, to make sure everything keeps working.
A conflict may cause other issues in addition to not letting Jetpack connect, so check for anything else not working properly after activating each plugin. If you find that a plugin is causing a conflict with Jetpack, please reach out to that plugin’s developers to see if there is a fix to get it working with Jetpack.
Theme Issues
If you’re using a theme that’s not coded to modern standards or kept up-to-date with changes in WordPress development, then the theme could be creating issues with Jetpack’s connection or features.
Download and temporarily switch to one of the more minimal, default WordPress themes (such as Twenty Twenty Two) and see if the connection issues are resolved. If so, then you’ll need to either replace your original theme or talk to its developers to see if they can figure out where the conflict is happening and how to solve it.
Testing Your Site Speed
Your site must initially respond within 5 seconds for the Jetpack connection to work correctly.
You can check your site speed and overall performance with a variety of tools (like GTmetrix or WebPageTest) and follow up with your webhost by showing them the results. They may be able to help improve your site’s response and loading times from there.
SSL Certificates
Your SSL certificate makes sure the traffic on your site is safe and secure. Sometimes they can be misconfigured or expired, which will keep Jetpack from connecting to it. You can check for errors on your SSL certificate with this SSL Checker and test its overall health with this SSL Server Test. It should typically be graded A or A+, and you shouldn’t see any errors.
The most common SSL errors that your webhost must fix are:
- Self-signed: The certificate was not created by using standard security practices and is considered unsafe
- Missing chain/intermediate certificate: Some SSL certificates are applied to your site in multiple parts. When one or more are missing in the chain, the security becomes broken and incomplete
- Expired: Just like a domain, an SSL certificate needs to be renewed each year, or it will expire. Certificate renewals usually happen without you having to do anything, but sometimes automatic systems at your webhost may fail to do so
HTTPS Settings
Check that both the SITE_URL and HOME_URL settings under Settings > General in your wp-admin dashboard are using https before your domain rather than just http. Sites that use only http are not secure and aren’t using the SSL certificate mentioned above – https loads the certificate properly and will allow Jetpack to connect to it.
Also, make sure that all of your site’s traffic routes to https as well. For example, any requests to http://example.com should automatically redirect to https://example.com instead. Your webhost can help make sure that this happens as expected.
For more detailed information on troubleshooting SSL issues, please refer to this guide.
Server Credentials for Jetpack Backup
If you have issues adding your credentials to Jetpack Backup, we recommend contacting your webhost and asking them to provide you with this information so you can then enter it successfully into your Jetpack settings:
- Credential type (FTP, SFTP, SSH)
- Server address
- Port number
- Server username
- Server password
- WordPress full installation path
When You Should Contact Your Webhost for Support
This list of issues that must be addressed by your hosting provider rather than Jetpack support because they are server-related:
- SSL certificates
- Changes in IP addresses or domains/URLs
- Migration from one server to another
- Site is down or not responding
- Errors (500 / 502 / 504 / 403)
- Server resource or memory usage
- DNS problems
- Outdated server software (PHP, MySQL, etc.)
- File and folder permissions
- Problems that are still occurring even after Jetpack is uninstalled
Просмотр 11 ответов — с 1 по 11 (всего 11)
Модератор
Yui
(@fierevere)
永子
Обычно бывает при запрете приема соединений по XML RPC
mysite.com/xmlrpc.php
любыми средствами, от плагинов безопасности и .htaccess, до запрета у хостера в конфигурации сервера.
вот что написанно там в .htaccess скорее всего не от этого
#BEGIN Really Simple SSL LETS ENCRYPT
RewriteRule ^.well-known/(.*)$ — [L]
#END Really Simple SSL LETS ENCRYPT
# Add trailing slash
RewriteCond %{REQUEST_URI} !^/wp-login
RewriteCond %{REQUEST_URI} !^/wp-admin
RewriteCond %{REQUEST_URI} !^/wp-content
RewriteCond %{REQUEST_URI} !^/wp-json
RewriteCond %{REQUEST_URI} /[^\.]+$
RewriteRule ^(.+[^/])$ https://%{SERVER_NAME}/$1/ [R=301,L]
# BEGIN WordPress
# The directives (lines) between «BEGIN WordPress» and «END WordPress» are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* — [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ — [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Модератор
Yui
(@fierevere)
永子
А у вас наверное не только с Jetpack могут быть проблемы
# Add trailing slash
RewriteCond %{REQUEST_URI} !^/wp-login
RewriteCond %{REQUEST_URI} !^/wp-admin
RewriteCond %{REQUEST_URI} !^/wp-content
RewriteCond %{REQUEST_URI} !^/wp-json
RewriteCond %{REQUEST_URI} /[^\.]+$
RewriteRule ^(.+[^/])$ https://%{SERVER_NAME}/$1/ [R=301,L]
вот этот опус вы откуда откопали?
не знаю, наверно от плагина
Модератор
Yui
(@fierevere)
永子
ну так удалите этот кусок и проверьте фунциональность Jetpack
а заодно в Консоль: Инструменты — Здоровье сайта
загляните на предмет замечаний возможных
удалил код, но бесполезно
По возможных вот что:
Рекомендуется удалить неактивные плагины
ПО СУБД устарело
Ваш сайт не использует локальные часовые пояса
Persistent object caching is not enabled
Модератор
Yui
(@fierevere)
永子
в меню Jetpack есть меню отладки
попробуйте обратиться на форум Jetpack с данной информацией
https://wordpress.org/support/plugin/jetpack/
Модератор
Yui
(@fierevere)
永子
я могу только сказать о том, что Jetpack у вас не подключен к wordpress.com, поддержка Jetpack (по ссылке данной вам выше),
возможно подскажет что-то еще
да создал тему, но ответа нет)
Просмотр 11 ответов — с 1 по 11 (всего 11)
Доброго времени суток Поддержка!
При активации плагина «Webcraftic Скрыть страницу логина» плагин JetPack выдает ошибку, подскажите пожалуйста как сделать что бы плагин JetPack работал при активном плагине «Webcraftic Скрыть страницу логина»
Заранее благодарю за ответ,
С уважением, Андрей
Temyk
Developer & Support
Здравствуйте, Андрей.
Раньше таких проблем не наблюдалось. Проблема с Джетпаком начинается сразу после активации «Webcraftic Скрыть страницу логина» или после настройки?
да, сразу после активации «Webcraftic Скрыть страницу логина», т.е. как я понимаю Джетпак ищет страницу входа в WP для прохождения верификации: http://мой_сайт.ua/wp-admin, а Webcraftic её получается скрывает, так как при отключениим»Webcraftic Скрыть страницу логина» и заново пройти процедуру верификации на странице самого Джетпака все снова работает
Temyk
Developer & Support
Попробовал на своём тестовом сайте, и у меня Джетпак продолжает нормально работать, после настройки Hide Login Page.
Попробуйте написать в техподдержку JetPack и уточнить из-за чего происходит такая ошибка подключения. Возможно влияют другие настройки или другие плагины.
Дело в том, что я изначально написал в техподдержку Джетпака в пятницу вечером, после чего они попросили написать свою проблему тут, типа спецы ответ в понедельник. Сейчас пришла мысль, включил плагин «Webcraftic Скрыть страницу логина» для того, что зайди на сайт Джетпака и указать сайт в виде скрытого адреса, так он (Джетпак) продолжает работать! Думаю тему можно закрыть, но факт проблемы остается фактом!, не знаю что это было но пока все работает тьфу, тьфу, тьфу )))