Viewing 6 replies — 1 through 6 (of 6 total)
Hi there,
The XML-RPC file should be under http://www.swampcrone.net/blog. I checked and it is correctly there so there is no problem related to this.
While your site is publicly accessible, and XML-RPC file is also working: https://swampcrone.net/blog/xmlrpc.php?for=jetpack, but for some reason, Jetpack is not able to make XML-RPC requests on your site. This file is used by Jetpack and other plugins and apps to connect to your site.
Can you please contact your hosting provider and check if they are blocking access to this file for Jetpack? Also, please find the IP ranges for the connection between your site and Jetpack/WordPress.com here, and whitelist them for and HTTP connections on your site:
- https://jetpack.com/support/how-to-add-jetpack-ips-allowlist
If you’re unsure about this, you may contact your hosting provider; they should be able to help you with this. Please note that these IP addresses could change (or more could be added) at any time. For that reason, we recommend your host uses the machine-readable versions of these IP ranges in JSON or plain text format to automate configuration changes on their systems.
Once we are able to access your site’s xmlrpc.php file, you should be able to connect Jetpack to https://wordpress.com.
Let me know how it goes!
Also, I checked your XML-RPC here: https://ratelimit.rudyfaile.com (you can also check) and found a “404 Not Found” response. The ideal response there should be “200 OK” which also indicates there is some issue from the host side. Please ask them about this and ask them to whitelist IP addresses as I mentioned above.
And tech support at my host is telling me to contact y’all. Even after I posted a copy of the conversation.
Well- it is sort of working- I get “Error updating settings. JsonParseError” when trying to update settings while in my website, but can change them at the .com site
Hi @swampcrone –
We aren’t seeing any errors on our end when we test your connection, so that part is at least solved. Are you still having issues with the settings?
If so, could you share a screenshot? You can send a screenshot using these instructions.
Hi there,
It has been more than one week since we have heard from you, so I’m marking this topic as resolved. But If you have any further questions or need some more help, you’re welcome to reply here or open another thread.
Viewing 6 replies — 1 through 6 (of 6 total)
Viewing 6 replies — 1 through 6 (of 6 total)
Hi there,
The XML-RPC file should be under http://www.swampcrone.net/blog. I checked and it is correctly there so there is no problem related to this.
While your site is publicly accessible, and XML-RPC file is also working: https://swampcrone.net/blog/xmlrpc.php?for=jetpack, but for some reason, Jetpack is not able to make XML-RPC requests on your site. This file is used by Jetpack and other plugins and apps to connect to your site.
Can you please contact your hosting provider and check if they are blocking access to this file for Jetpack? Also, please find the IP ranges for the connection between your site and Jetpack/WordPress.com here, and whitelist them for and HTTP connections on your site:
- https://jetpack.com/support/how-to-add-jetpack-ips-allowlist
If you’re unsure about this, you may contact your hosting provider; they should be able to help you with this. Please note that these IP addresses could change (or more could be added) at any time. For that reason, we recommend your host uses the machine-readable versions of these IP ranges in JSON or plain text format to automate configuration changes on their systems.
Once we are able to access your site’s xmlrpc.php file, you should be able to connect Jetpack to https://wordpress.com.
Let me know how it goes!
Also, I checked your XML-RPC here: https://ratelimit.rudyfaile.com (you can also check) and found a “404 Not Found” response. The ideal response there should be “200 OK” which also indicates there is some issue from the host side. Please ask them about this and ask them to whitelist IP addresses as I mentioned above.
And tech support at my host is telling me to contact y’all. Even after I posted a copy of the conversation.
Well- it is sort of working- I get “Error updating settings. JsonParseError” when trying to update settings while in my website, but can change them at the .com site
Hi @swampcrone –
We aren’t seeing any errors on our end when we test your connection, so that part is at least solved. Are you still having issues with the settings?
If so, could you share a screenshot? You can send a screenshot using these instructions.
Hi there,
It has been more than one week since we have heard from you, so I’m marking this topic as resolved. But If you have any further questions or need some more help, you’re welcome to reply here or open another thread.
Viewing 6 replies — 1 through 6 (of 6 total)
На чтение 3 мин Просмотров 694 Опубликовано 2017-02-04
Обновлено 2017-04-28
Популярнейший плагин от разработчиков cms wordpress jetpack установлен у многих блогеров. На своем блоге также установил сей комбайн. Это непросто плагин. По функционалу это несколько плагинов в одном. Однако эта небольшая заметка будет не о функционале, а проблеме, с которой я столкнулся при его использовании.
Когда первый раз установил jetpack на свой блог, проблем с установкой и настройкой не возникло. Через какое-то время мой блог переехал на хостинг от Beget. Отличный хостинг оказался. Кто ищет новый дом для сайта — лучше места не найти. Так как хостер предоставлял бесплатно ssl сертификат, попутно с переездом блог был переведен на протокол https.
И тут, нормально работающий jetpack, отказался работать. Типа нужно авторизоваться на wordpress.com. Странно, плагин уже был авторизован. Ну и ничего страшного. Несложно же нажать кнопочку. Жму и получаю интересный ответ от системы
Извините, вам не разрешено просматривать эту страницу.
Здрасьте, приехали. Как это не разрешено? Начал поиски источника проблемы. Первым делом отключил все плагины, кроме jetpack. Пробую авторизоваться — результат тот же.
Смотрю файл .htaccess. Защитные плагины обычно прописывают там свои правила. И даже при удалении могут эти правила там оставлять. В итоге ничего странного в файле не обнаружено. На всякий случай заменил его дефолтным.
Проверил, а не появился ли, случаем, лишний пользователь с правами администратора. Нет таких. Пришлось перелопачивать интернет. Однако ничего вразумительного нарыть так и не смог не смог.
Стал грешить на некорректный перевод блога на протокол https. Все работает. Плагины, скрипты. А вот jtpack ни в какую. И уже от отчаяния написал в техподдержку своего нового хостинга Beget. Получил ответ, мол поправили. Проверяю — jetpack работает. Авторизация проходит на ура. Интересуюсь у техподдержки, а что собственно поправили-то?
Решение проблемы
В итоге все оказалось до банальности просто. При работе плагин использует файл движка xmlrpc.php. На хостинге этот файл по умолчанию заблокирован, так как через него часто ломают wordpress. И для моего аккаунта его разблокировали. Немного странное решение со стороны хостинга. Вот попробуй догадайся об этом.
Так что если у вас такая же ситуация с плагином jetpack, поинтересуйтесь у своего хостера. Может, он тоже как и бегет блокирует этот файл. На этом все. Пишите в комментариях, какие непонятки возникали у вас с хостерами. Интересно же.
Недавно переносил один сайт на WordPress на новый хостинг — beget.ru, возникла проблема при активации плагина JetPack. А именно, при попытке активировать плагин вылетает ошибка 403, а при попытке посмотреть куда идёт плагин вообще 405. Оказалось всё проще, чем я думал.
При попытке активировать плагин вылетает ошибка со следующим текстом:
Ваш сайт должен быть в открытом доступе, чтобы иметь возможность использовать 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
Быстрый поиск в интернете не дал результатов. В основном советовали потестировать cms на ошибки, править .htaccess и т.д. Но проблема оказалась решается куда проще. Плагин пытался получить доступ к файлу по адресу http://site-name.ru/xmlrpc.php, но многие хостеры ограничивают это возможность. Написал в тех поддержку хостинга, и оказалось, действительно ошибка возникала из-за ограничений, которые были установлены на хостинге.
Хостер снял ограничение и всё отлично заработало. Так что, если у вас возникает ошибка Jetpack: site_inaccessible при работе с плагином JetPack, то смело пишите в тех поддержку хостинга. На этом всё, проблема решена.
comments powered by HyperComments
Просмотр 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)
В связи с перездом на «зимнюю квартиру» и сменой интернет-провайдера, а значит сменой собственного IP-адреса, я получил неожиданный сюрприз. Установленный мною несравненный плагин для WordPress на этом сайте — Jetpack, принцип работы которого в сфере статистики посещаемости сайта я немного описал в статье «Сервис статистики от плагина Jetpack», выдал сюрприз от его системы безопасности: он просто не пустил меня в админпанель блога.
Плагин не дал авторизоваться из-за смены IP-адреса, посчитав мой новый потенциально опасным. Это не шутка и, что примечательно, данный «розыгрыш» произошел аж месяц спустя, после того, как я сменил провайдера! Ничего себе реакция… 🙂
Содержание
- 1 Как устранить проблему авторизации на своем сайте, учитывая блокировку IP-адреса плагином Jetpack
- 1.1 1.Добавляем IP-адрес в разделе плагина на сайте wordpress.com
- 1.2 2. Добавляем запись в файл wp-config.php
- 1.3 Related Posts
Такую проблему, однако, предлагают решить сами авторы плагина. Совет открывается при переходе по ссылке в окне блокировки. Кликаем по ней и попадаем на страницу сайта плагина, в котором подробно (на английском языке) объясняется, что необходимо сделать администратору сайта, чтобы разблокировать вход в админку собственного сайта. Как оказалось, таких способа два.
1.Добавляем IP-адрес в разделе плагина на сайте wordpress.com
Для тех, кто установил плагин Jetpack, известно, что администратору необходимо автризоваться на сайте wordpress.com и, желательно, добавить туда свой сайт. Поэтому первый способ основан на том, что при установке плагина, он, сразу определив IP-адрес администратора сайта, вносит автоматически в разряд безопасных. Но может случиться, как у меня, что при смене этого адреса, плагин почему-то определит новый адрес небезопасным (бывает такое). Для того, чтобы исправить положение, нам придется перейти на страницу плагина в wordpress.com, перейти на вкладку «My Sites» (Мои сайты»), выбрать нужный сайт (если вы установили плагин на более, чем один сайт), кликнуть в меню (в самом низу) по ссылке «Settings» («Настройки»), а затем в открывшемся меню, вызвать информацию ссылкой «Security» («Безопасность»).
Далее все просто, в нужном окне добавляем ваш новый IP-адрес и обновляем настройки. Здесь же можно добавить любые IP-адреса, которые администрация считает безопасными (это могут быть авторы контента, другие пользователи сайтом, например).
На картинке, кстати, отображенеы два моих адреса — верхний, был у меня ранее, в тот время, когда я установил плагин Jetpack.
2. Добавляем запись в файл wp-config.php
Авторы плагина предлагают так же еще один простой способ разблокировки IP-адреса. Все что необходимо сделать — добавить в файл сайта под названием wp-config.php вот такую строку :
DEFINE (‘JETPACK_IP_ADDRESS_OK’, ‘XXXXX‘);
Красным выделено число — это нужный вам IP-адрес. Замените, вставив нужный. У меня теперь это число 5.153.128.67.
Всё! Желаю всем успехов!
(Visited 45 times, 1 visits today)
Приветствую всех, кто так или иначе связан с wordpress.
Небольшое вступление.. Все началось с того, что у меня был установлен плагин Джетпак и замечательно работал, но я захотел подключить один из его модулей по автопостингу в фб, твиттер и g+. После тщетных попыток это сделать я начал рыться в сети. Самое частое решение, что встречал — это отключить сам джетпак от аккаунта в вордпресс.ком и заново подключить.
Ну чтож, я так и сделал. Но обратно подключиться я уже не смог. Плагин устанавливается нормально и следующим шагом идет подключения к вордпресс. Вроде бы простая операция, но выходит ошибка xml_rpc-32700 и ничего не могу с ней поделать уже кучу способов перепробовал и толку 0. Хотя до этого все подключилось запросто.
Кто сталкивался и сможет помочь в этом?
В Jetpack произошла ошибка. Приносим извинения. Повторите попытку позже. Если устранить неполадку не удастся, отправьте в службу поддержки следующее сообщение. xml_rpc-32700
Попробуйте соединиться снова.
Сайт службы поддержки у меня не открывается почему-то.
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.
Действия по воспроизведению проблемы
- Это немного сложно, так как вам нужно принудительно отключить соединение
- Попробуйте подключиться через подключение на месте
- Видите, что кнопка «Повторить попытку» неправильно выровнена
Что я ожидал
не уверен, на самом деле. Следует ли «Повторить попытку» заменить кнопку «Подтвердить»?
Что случилось вместо
Connect Flow
[Pri] High
[Status] Needs Design Review
[Type] Bug
Все 9 Комментарий
Отмечен как высокий приоритет, поскольку подобные ошибки подключения могут происходить довольно часто и поскольку это не произведет хорошего первого впечатления, я думаю, что мы должны уделять первоочередное внимание исправлению этого.
Это должно быть исправлено после объединения кода D47074.
это будет выглядеть так:
@ Automattic / jetpack-design Могу я побеспокоить вас проверкой работоспособности вышеупомянутого обновления стиля?
Вышесказанное кажется мне хорошим решением. 👍
Может быть: можем ли мы более подробно рассказать о том, что пошло не так? Есть ли шанс, не будучи слишком техничным?
Эти ошибки происходят из ответа WPCOM /jetpack-blogs/$clientId/authorize
, поэтому мы действительно можем их обработать. Хотя это может быть непростое изменение. Я бы предпочел оставить это исправление, чтобы оно оставалось связанным со стилем.
Интересно, есть ли у нас планы по рассмотрению этих сообщений об ошибках в рамках нашего внимания к подключению? (не уверен, к кому обратиться по поводу вышеуказанного вопроса, поэтому cc @ kbrown9 @leogermani)
Да, имеет смысл сначала исправить визуал. Я спрашивал, когда на первом экране было что-то другое — давайте продолжим.
Ах! На втором снимке экрана я «имитировал» ошибку подключения, перейдя в автономный режим. Обычно должна быть значимая ошибка, как в описании проблемы.
Развернуто через r211170-wpcom
Интересно, есть ли у нас планы по рассмотрению этих сообщений об ошибках в рамках нашего внимания к подключению?
Как видно из первого снимка экрана, текущие сообщения об ошибках не очень полезны. У нас есть планы по работе над улучшением сообщений об ошибках подключения.
Была ли эта страница полезной?
0 / 5 — 0 рейтинги
На чтение 3 мин Просмотров 756 Опубликовано 2017-02-04
Обновлено 2017-04-28
Популярнейший плагин от разработчиков cms wordpress jetpack установлен у многих блогеров. На своем блоге также установил сей комбайн. Это непросто плагин. По функционалу это несколько плагинов в одном. Однако эта небольшая заметка будет не о функционале, а проблеме, с которой я столкнулся при его использовании.
Странное поведение плагина jetpack
Когда первый раз установил jetpack на свой блог, проблем с установкой и настройкой не возникло. Через какое-то время мой блог переехал на хостинг от Beget. Отличный хостинг оказался. Кто ищет новый дом для сайта — лучше места не найти. Так как хостер предоставлял бесплатно ssl сертификат, попутно с переездом блог был переведен на протокол https.
И тут, нормально работающий jetpack, отказался работать. Типа нужно авторизоваться на wordpress.com. Странно, плагин уже был авторизован. Ну и ничего страшного. Несложно же нажать кнопочку. Жму и получаю интересный ответ от системы
Извините, вам не разрешено просматривать эту страницу.
Здрасьте, приехали. Как это не разрешено? Начал поиски источника проблемы. Первым делом отключил все плагины, кроме jetpack. Пробую авторизоваться — результат тот же.
Смотрю файл .htaccess. Защитные плагины обычно прописывают там свои правила. И даже при удалении могут эти правила там оставлять. В итоге ничего странного в файле не обнаружено. На всякий случай заменил его дефолтным.
Проверил, а не появился ли, случаем, лишний пользователь с правами администратора. Нет таких. Пришлось перелопачивать интернет. Однако ничего вразумительного нарыть так и не смог не смог.
Стал грешить на некорректный перевод блога на протокол https. Все работает. Плагины, скрипты. А вот jtpack ни в какую. И уже от отчаяния написал в техподдержку своего нового хостинга Beget. Получил ответ, мол поправили. Проверяю — jetpack работает. Авторизация проходит на ура. Интересуюсь у техподдержки, а что собственно поправили-то?
Решение проблемы
В итоге все оказалось до банальности просто. При работе плагин использует файл движка xmlrpc.php. На хостинге этот файл по умолчанию заблокирован, так как через него часто ломают wordpress. И для моего аккаунта его разблокировали. Немного странное решение со стороны хостинга. Вот попробуй догадайся об этом.
Так что если у вас такая же ситуация с плагином jetpack, поинтересуйтесь у своего хостера. Может, он тоже как и бегет блокирует этот файл. На этом все. Пишите в комментариях, какие непонятки возникали у вас с хостерами. Интересно же.
Hey there @alexsender1965,
We’re only able to provide support in English, so I’ll be replying in English, but please continue writing in Russian if you prefer. We’ll use Google Translate to understand your replies.
I understand you’re experiencing an error when you try to load Jetpack > Dashboard. It looks like your site’s connection to the Jetpack plugin is currently broken, so we’ll want to get that resolved first and see if it clears up your dashboard error.
Jetpack communicates with your site via XML-RPC. When we try to communicate with your site, we are encountering the following error:
503 Service Unavailable
The server is temporarily busy, please try again later!
This particular error usually means that you are exhausting the available memory or resources on the site. If you get in touch with your web host and let them know you are encountering 503 errors, they should be able to check their server error logs and see what is going on.
It has been more than one week since we have heard from you, so I’m marking this topic as resolved.
But if you have any further questions or need some more help, you’re welcome to reply here or open another thread.
Недавно переносил один сайт на WordPress на новый хостинг — beget.ru, возникла проблема при активации плагина JetPack. А именно, при попытке активировать плагин вылетает ошибка 403, а при попытке посмотреть куда идёт плагин вообще 405. Оказалось всё проще, чем я думал.
При попытке активировать плагин вылетает ошибка со следующим текстом:
Ваш сайт должен быть в открытом доступе, чтобы иметь возможность использовать 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
Быстрый поиск в интернете не дал результатов. В основном советовали потестировать cms на ошибки, править .htaccess и т.д. Но проблема оказалась решается куда проще. Плагин пытался получить доступ к файлу по адресу http://site-name.ru/xmlrpc.php, но многие хостеры ограничивают это возможность. Написал в тех поддержку хостинга, и оказалось, действительно ошибка возникала из-за ограничений, которые были установлены на хостинге.
Хостер снял ограничение и всё отлично заработало. Так что, если у вас возникает ошибка Jetpack: site_inaccessible при работе с плагином JetPack, то смело пишите в тех поддержку хостинга. На этом всё, проблема решена.
comments powered by HyperComments
Просмотр 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)
В связи с перездом на «зимнюю квартиру» и сменой интернет-провайдера, а значит сменой собственного IP-адреса, я получил неожиданный сюрприз. Установленный мною несравненный плагин для WordPress на этом сайте — Jetpack, принцип работы которого в сфере статистики посещаемости сайта я немного описал в статье «Сервис статистики от плагина Jetpack», выдал сюрприз от его системы безопасности: он просто не пустил меня в админпанель блога.
Плагин не дал авторизоваться из-за смены IP-адреса, посчитав мой новый потенциально опасным. Это не шутка и, что примечательно, данный «розыгрыш» произошел аж месяц спустя, после того, как я сменил провайдера! Ничего себе реакция… 🙂
Такую проблему, однако, предлагают решить сами авторы плагина. Совет открывается при переходе по ссылке в окне блокировки. Кликаем по ней и попадаем на страницу сайта плагина, в котором подробно (на английском языке) объясняется, что необходимо сделать администратору сайта, чтобы разблокировать вход в админку собственного сайта. Как оказалось, таких способа два.
1.Добавляем IP-адрес в разделе плагина на сайте wordpress.com
Для тех, кто установил плагин Jetpack, известно, что администратору необходимо автризоваться на сайте wordpress.com и, желательно, добавить туда свой сайт. Поэтому первый способ основан на том, что при установке плагина, он, сразу определив IP-адрес администратора сайта, вносит автоматически в разряд безопасных. Но может случиться, как у меня, что при смене этого адреса, плагин почему-то определит новый адрес небезопасным (бывает такое). Для того, чтобы исправить положение, нам придется перейти на страницу плагина в wordpress.com, перейти на вкладку «My Sites» (Мои сайты»), выбрать нужный сайт (если вы установили плагин на более, чем один сайт), кликнуть в меню (в самом низу) по ссылке «Settings» («Настройки»), а затем в открывшемся меню, вызвать информацию ссылкой «Security» («Безопасность»).
Далее все просто, в нужном окне добавляем ваш новый IP-адрес и обновляем настройки. Здесь же можно добавить любые IP-адреса, которые администрация считает безопасными (это могут быть авторы контента, другие пользователи сайтом, например).
На картинке, кстати, отображенеы два моих адреса — верхний, был у меня ранее, в тот время, когда я установил плагин Jetpack.
2. Добавляем запись в файл wp-config.php
Авторы плагина предлагают так же еще один простой способ разблокировки IP-адреса. Все что необходимо сделать — добавить в файл сайта под названием wp-config.php вот такую строку :
DEFINE (‘JETPACK_IP_ADDRESS_OK’, ‘XXXXX‘);
Красным выделено число — это нужный вам IP-адрес. Замените, вставив нужный. У меня теперь это число 5.153.128.67.
Всё! Желаю всем успехов!
(Visited 45 times, 1 visits today)
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.
Перейти к содержимому
Заметил как-то ошибку при активации Jetpack:
The Jetpack server encountered the following client error: Verification secrets not found
Причину нашел в ограниченном доступе по IP через .htaccess к файлу wp-login.php, как оказалось доступ к этому файлу нельзя блокировать если используется Jetpack.
По этому нашел строки ограничивающие доступ и закомментировал их поставив перед каждой строкой символ # (строки могут быть как в файле .htaccess находящемся в корневой директории с WordPress так и в файлах конфигурации web-сервера), пример:
# <files wp-login.php> # order allow,deny # allow from 127.0.0.1 192.168.2.50 # </files>
Если строки были в .htaccess, то Jetpack уже можно активировать, если в файлах конфигурации web-сервера, то нужно еще выполнить его перезагрузку чтобы применить изменения.
Также ошибка может возникать из-за конфликтующих плагинов, можно попробовать отключить их по очереди.