Rest api ошибка 404

Handling 404 Errors¶

We’re handling validation errors and invalid JSON errors. The last big thing
is to properly handle 404 errors. In showAction and updateAction,
we’re throwing a special type of exception class to trigger a 404 response.
But in reality, the 404 response isn’t JSON: it’s a big HTML page. You can
see this by browsing to a made-up programmer:

And actually, if we go to a completely made-up URL, we also see this same
HTML page:

Internally, Silex throws that same exception to cause this 404 page.

Somehow, we need to be able to return JSON for all exceptions and
while we are at it we should use the API problem detail format.

# features/api/programmer.feature
# ...

Scenario: Proper 404 exception on no programmer
  When I request "GET /api/programmers/fake"
  Then the response status code should be 404
  And the "Content-Type" header should be "application/problem+json"
  And the "type" property should equal "about:blank"
  And the "title" property should equal "Not Found"

// src/KnpU/CodeBattle/Application.php
// ...

public function configureListeners()
{
    $app = $this;

    $this->error(function(Exception $e, $statusCode) use ($app) {
        // only act on /api URLs
        if (strpos($app['request']->getPathInfo(), '/api') !== 0) {
            return;
        }

        // ...

        return $response;
    });
}

// src/KnpU/CodeBattle/Application.php
// ...

$this->error(function(Exception $e, $statusCode) use ($app) {
    // only act on /api URLs
    if (strpos($app['request']->getPathInfo(), '/api') !== 0) {
        return;
    }

    if ($e instanceof ApiProblemException) {
        $apiProblem = $e->getApiProblem();
    } else {
        $apiProblem = new ApiProblem($statusCode);
    }

    // ...
});

// src/KnpU/CodeBattle/Api/ApiProblem.php
// ...

public function __construct($statusCode, $type = null)
{
    $this->statusCode = $statusCode;
    $this->type = $type;

    if (!$type) {
        // no type? The default is about:blank and the title should
        // be the standard status code message
        $this->type = 'about:blank';
        $this->title = isset(Response::$statusTexts[$statusCode])
            ? Response::$statusTexts[$statusCode]
            : 'Unknown HTTP status code :(';
    } else {
        if (!isset(self::$titles[$type])) {
            throw new InvalidArgumentException('No title for type '.$type);
        }

        $this->title = self::$titles[$type];
    }
}

// src/KnpU/CodeBattle/Application.php
// ...

$this->error(function(Exception $e, $statusCode) use ($app) {
    // ...

    $response = new JsonResponse(
        $apiProblem->toArray(),
        $statusCode
    );
    $response->headers->set('Content-Type', 'application/problem+json');

    return $response;
});

// src/KnpU/CodeBattle/Application.php
// ...

$data = $apiProblem->toArray();
if ($data['type'] != 'about:blank') {
    $data['type'] = 'http://localhost:8000/api/docs/errors#'.$data['type'];
}
$response = new JsonResponse(
    $data,
    $statusCode
);

# features/api/programmer.feature
# ...

Scenario: Error response on invalid JSON
  # ...
  And the "type" property should contain "/api/docs/errors#invalid_body_format"

This tutorial uses a deprecated micro-framework called Silex. The fundamentals of REST are still ? valid, but the code we use can’t be used in a real application.

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "silex/silex": "~1.0", // v1.3.2
        "symfony/twig-bridge": "~2.1", // v2.7.3
        "symfony/security": "~2.4", // v2.7.3
        "doctrine/dbal": "^2.5.4", // v2.5.4
        "monolog/monolog": "~1.7.0", // 1.7.0
        "symfony/validator": "~2.4", // v2.7.3
        "symfony/expression-language": "~2.4" // v2.7.3
    },
    "require-dev": {
        "behat/mink": "~1.5", // v1.5.0
        "behat/mink-goutte-driver": "~1.0.9", // v1.0.9
        "behat/mink-selenium2-driver": "~1.1.1", // v1.1.1
        "behat/behat": "~2.5", // v2.5.5
        "behat/mink-extension": "~1.2.0", // v1.2.0
        "phpunit/phpunit": "~5.7.0", // 5.7.27
        "guzzle/guzzle": "~3.7" // v3.9.3
    }
}

If you’re encountering some oddities in the API, here’s a list of resolutions to
some of the problems you may be experiencing.

400 error for an unsupported API version

You should use the X-GitHub-Api-Version header to specify an API version. For example:

$ curl --header "X-GitHub-Api-Version:2022-11-28" https://api.github.com/zen

If you specify a version that does not exist, you will receive a 400 error.

For more information, see «API Versions.»

404 error for an existing repository

Typically, we send a 404 error when your client isn’t properly authenticated.
You might expect to see a 403 Forbidden in these cases. However, since we don’t
want to provide any information about private repositories, the API returns a
404 error instead.

To troubleshoot, ensure you’re authenticating correctly, your OAuth access token has the required scopes, third-party application restrictions are not blocking access, and that the token has not expired or been revoked.

Not all results returned

Most API calls accessing a list of resources (e.g., users, issues, etc.) support
pagination. If you’re making requests and receiving an incomplete set of results, you’re
probably only seeing the first page. You’ll need to request the remaining pages
in order to get more results.

It’s important to not try and guess the format of the pagination URL. Not every
API call uses the same structure. Instead, extract the pagination information from
the link header, which is returned with every request. For more information about pagination, see «Using pagination in the REST API.»

Basic authentication errors

On November 13, 2020 username and password authentication to the REST API and the OAuth Authorizations API were deprecated and no longer work.

Using username/password for basic authentication

If you’re using username and password for API calls, then they are no longer able to authenticate. For example:

curl -u my_user:my_password https://api.github.com/user/repos

Instead, use a personal access token when testing endpoints or doing local development:

curl -H 'Authorization: Bearer my_access_token' https://api.github.com/user/repos

For OAuth Apps, you should use the web application flow to generate an OAuth token to use in the API call’s header:

curl -H 'Authorization: Bearer my-oauth-token' https://api.github.com/user/repos

Timeouts

If GitHub takes more than 10 seconds to process an API request, GitHub will terminate the request and you will receive a timeout response.

REST APIs use the Status-Line part of an HTTP response message to inform clients of their request’s overarching result. RFC 2616 defines the Status-Line syntax as shown below:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP defines these standard status codes that can be used to convey the results of a client’s request. The status codes are divided into five categories.

• 1xx: Informational – Communicates transfer protocol-level information.
• 2xx: Success – Indicates that the client’s request was accepted successfully.
• 3xx: Redirection – Indicates that the client must take some additional action in order to complete their request.
• 4xx: Client Error – This category of error status codes points the finger at clients.
• 5xx: Server Error – The server takes responsibility for these error status codes.

1xx Status Codes [Informational]

2xx Status Codes [Success]

3xx Status Codes [Redirection]

4xx Status Codes (Client Error)

5xx Status Codes (Server Error)

6. REST Specific HTTP Status Codes

200 (OK)

It indicates that the REST API successfully carried out whatever action the client requested and that no more specific code in the 2xx series is appropriate.

Unlike the 204 status code, a 200 response should include a response body. The information returned with the response is dependent on the method used in the request, for example:

• GET an entity corresponding to the requested resource is sent in the response;
• HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
• POST an entity describing or containing the result of the action;
• TRACE an entity containing the request message as received by the end server.

201 (Created)

A REST API responds with the 201 status code whenever a resource is created inside a collection. There may also be times when a new resource is created as a result of some controller action, in which case 201 would also be an appropriate response.

The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.

The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with a 202 (Accepted) response instead.

202 (Accepted)

A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.

Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed.

The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor (job queue location) or some estimate of when the user can expect the request to be fulfilled.

204 (No Content)

The 204 status code is usually sent out in response to a PUT, POST, or DELETE request when the REST API declines to send back any status message or representation in the response message’s body.

An API may also send 204 in conjunction with a GET request to indicate that the requested resource exists, but has no state representation to include in the body.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view. However, any new or updated metainformation SHOULD be applied to the document currently in the user agent’s dynamic view.

The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields.

301 (Moved Permanently)

The 301 status code indicates that the REST API’s resource model has been significantly redesigned, and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header, and all future requests should be directed to the given URI.

You will hardly use this response code in your API as you can always use the API versioning for the new API while retaining the old one.

302 (Found)

The HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the Location header field. The user agent (e.g., a web browser) is invited by a response with this code to make a second. Otherwise identical, request to the new URL specified in the location field.

Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g., POST). RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

303 (See Other)

A 303 response indicates that a controller resource has finished its work, but instead of sending a potentially unwanted response body, it sends the client the URI of a response resource. The response can be the URI of the temporary status message, or the URI to some already existing, more permanent, resource.

Generally speaking, the 303 status code allows a REST API to send a reference to a resource without forcing the client to download its state. Instead, the client may send a GET request to the value of the Location header.

The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

304 (Not Modified)

This status code is similar to 204 (“No Content”) in that the response body must be empty. The critical distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.

In such a case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.

307 (Temporary Redirect)

A 307 response indicates that the REST API is not going to process the client’s request. Instead, the client should resubmit the request to the URI specified by the response message’s Location header. However, future requests should still use the original URI.

A REST API can use this status code to assign a temporary URI to the client’s requested resource. For example, a 307 response can be used to shift a client request over to another host.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

400 (Bad Request)

400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.

The client SHOULD NOT repeat the request without modifications.

401 (Unauthorized)

A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information.

403 (Forbidden)

A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it, i.e., the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”).

Authentication will not help, and the request SHOULD NOT be repeated. Unlike a 401 Unauthorized response, authenticating will make no difference.

404 (Not Found)

The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.

No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

405 (Method Not Allowed)

The API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.

A 405 response must include the Allow header, which lists the HTTP methods that the resource supports. For example:

Allow: GET, POST

406 (Not Acceptable)

The 406 error response indicates that the API is not able to generate any of the client’s preferred media types, as indicated by the Accept request header. For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

412 (Precondition Failed)

The 412 error response indicates that the client specified one or more preconditions in its request headers, effectively telling the REST API to carry out its request only if certain conditions were met. A 412 response indicates that those conditions were not met, so instead of carrying out the request, the API sends this status code.

415 (Unsupported Media Type)

The 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json.

For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

500 (Internal Server Error)

500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.

A 500 error is never the client’s fault, and therefore, it is reasonable for the client to retry the same request that triggered this response and hope to get a different response.

The API response is the generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 (Not Implemented)

The server either does not recognize the request method, or it cannot fulfill the request. Usually, this implies future availability (e.g., a new feature of a web-service API).

References :

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

WordPress REST API does not respond: What’s the problem?

If you only see a loading animation, but the actual content in one of our plugins does not load, your WordPress REST API is most likely not reachable.

What is the WordPress REST API?

A REST API is generally a standardized method that many applications on the Internet use to communicate between server and client. WordPress v4.7 introduced the WordPress REST API, which allows modern WordPress plugins to use this standard method for communication instead of the WordPress specific way of communication.

How can I enable the WordPress REST API in my website?

The WordPress REST API is enabled by default in your WordPress website. It is a standard method of communication and there is no additional risk to have it activated compared to other methods how WordPress plugins communicate between client and server. But some WordPress plugins allow you as WordPress admin to disable the REST API. The reason for deactivation is usually the desire for better performance or security concerns. For both aspects, however, disabling the REST API is usually not a suitable means.

We know the following plugins that allow you to disable the REST API. By default, none of these plugins disable the REST API, but they can optionally disable it:

Additionally, you can restrict access to the REST API in your web server configuration (usually Apache2 or NGINX). This can be done intentionally or accidentally by rejecting requests that start with /wp-json/ .

How do I know if the unreachable REST API is my issue?

You can easily check if an unreachable REST API is the problem when you see only a loading animation in a devowl.io WordPress plugin. Just follow these steps:

1. Open a new tab where you access your website.
2. Right-click into the web page to open the panel “Inspect” (Google Chrome) or “Inspect Element” (Mozilla Firefox). Here you can go to the “Console” tab.
3. Now open the page on which you see the loading animation that does not disappear.
4. In the console, you should see an entry marked red as an error, which indicates an error 401, 403, 404 or 500 (depending on your plugin/configuration to disable the REST API).

If you see an error like this, you need to make sure that the WordPress REST API is reachable again.

I do not want to enable the REST API in general, but for your plugin. Is this possible?

This depends on the configuration of the plugin you use to restrict access to the REST API. For example, with Cerber Security, Anti-spam & Malware Scan you can disable the REST API using namespaces. Each plugin that uses the WordPress REST API must register a namespace in which all endpoints are registered. For example, if you access /wp-json/realmedialibrary/v1 in your WordPress REST API, the namespace is called realmedialibrary/v1 .

We use for the devowl.io WordPress plugins the following namespaces:

• Real Media Library: realmedialibrary/v1
• Real Physical Media: real-physical-media/v1
• Real Category Management: real-category-library/v1
• Real Thumbnail Generator: real-thumbnail-generator/v1
• Real Custom Post Order: real-custom-post-order/v1
• Real Cookie Banner: real-cookie-banner/v1 (must be available for everyone, not only for logged-in users)

Besides WordPress plugins, we also use third-party packages that are consumed by our plugins. For this, you still have to release the following name ranges:

• Real Product Manager (license and update client, all plugins): real-product-manager-wp-client/v1
• Real Queue (queue management, currently only used in Real Cookie Banner): real-queue/v1

I am using a plugin like “JWT Auth”. Is it compatible?

If you need to use a plugin like JWT Auth you also need to whitelist our plugins. In case of JWT Auth, you have to read the section “Whitelisting Endpoints” in its README file and add our plugins to the allowed endpoints. The endpoints can be found in the paragraph above.

Permalinks are broken

If you use Apache2 as web server, the .htaccess file defines how URLs of your website look like. This file is created automatically and sometimes manipulated by plugins. If something went wrong with the creation, this can also be a reason why the WP REST API can no longer be accessible.

So, you can rewrite the rules in the .htaccess file:

1. Go to Settings > Permalinks in your WordPress backend.
2. Save the unchanged settings. Saving will trigger the rules to be rewritten.

I can read data but not write?

You are using Real Cookie Banner and cannot save your licence or create folders in Real Media Library? A typical error message text is:

Missing parameter(s): terms (or similar field names)

The most commonly identified cause of this behaviour with previous clients was that your server is configured to forward URLs without an ending slash / to URLs with an ending slash / (or vice versa).

You can track this by checking the respective requests via F12 > Network to see if a POST request is redirected. A POST request must not be redirected and therefore leads to errors, as data to be saved (your input) is not redirected.

It is best to check your .htaccess file to see if you can exclude /wp-json from URL forwarding.

Источник

REST API не работает корректно

Плагин «Здоровье сайта» показывает две ошибки:
1) REST API не смог корректно обработать параметр запроса context
2) Плагин предотвращает обновления отключением wp_version_check(). (подозреваю, что это из-за п.1)

Сервер nginx+php7.4 без Apache. Движок и плагины обновлены до последних версий.
В шаблоне были инструкции по блокировке REST API — убрал их. Больше ничего не нашёл.
Отключение всех плагинов и шаблона проблему не решает (режим решения проблем). Настройки пермалинков обновлял. Гугл ничего полезного не даёт.

Есть идеи, в какую строну копать?

у вас открывается что-то по адресу
вашсайт/wp-json/wp/v2/users/
?

Плагин «Здоровье сайта» показывает две ошибки:
1) REST API не смог корректно обработать параметр запроса context

в предыдущих версиях такое могло показываться и в виде ложного срабатывания.
Поэтому стоит смотреть не на это конкретное сообщение, а на работу REST API в целом, например функционирование редактора блоков.

2) Плагин предотвращает обновления отключением wp_version_check().

иногда тоже ложно срабатывает при просрочке wp_cron
Обновление плагинов и тем в консоли у вас работает?
Проверка обновлений, сами обновления?

у вас открывается что-то по адресу
вашсайт/wp-json/wp/v2/users/

Да, выдаёт информацию о пользователе.

например функционирование редактора блоков.

Насколько я вижу — работает нормально.

Обновление плагинов и тем в консоли у вас работает?

Да. Специально изменил у одного плагина цифру в версии — сразу же выпало предупреждение о необходимости обновиться и обновление прошло успешно.

иногда тоже ложно срабатывает при просрочке wp_cron

Принудительно запустил все запланированные задачи — не помогло, ничего не изменилось.

Вообще, эта ошибка (про обновление) появилась именно после удаления кода, отключающего REST API. По самому REST API была ошибка 404 (что логично), но после удаления кода показывает проблему с контекстом.

В итоге, как я понял, всё работает хорошо, но всё же, что-то мешает проверке пройти нормально. Чисто из исследовательского интереса хотелось бы выяснить причину. И может ли это как быть связано с настройками сервера? Сервер у меня свой, могу поковырять настройки, если укажете, куда смотреть.

эта ошибка (про обновление) появилась именно после удаления кода, отключающего REST API

настройки ЧПУ вы обновляли…

проверка тоже далека от абсолютного совершенства
можете с плагином попробовать, https://ru.wordpress.org/plugins/health-check/
там чуть более свежий код этого компонента (+доп инструменты)

Да и в целом, если все работает и не создает реальных проблем, то наверное можно и отложить поиск проблем на ровном месте на неопределенное время (до обновления WP до следующего значимого выпуска (к концу марта) или плагина health-check)

Собственно, весь разговор именно о нём. Это он мне такие ошибки показывает.

если все работает и не создает реальных проблем, то наверное можно и отложить поиск проблем

Хорошо, согласен. Просто не люблю, когда остаётся что-то непонятное, да ещё и в виде ошибки.

Собственно, весь разговор именно о нём. Это он мне такие ошибки показывает.

есть плагин, есть штатный компонент WordPress 5.2+
в плагине есть инструменты, в штатном компоненте их нет.

Сравните кстати, с деактивированным плагином, будут ли те же замечания или они пропадут ?

есть плагин, есть штатный компонент WordPress 5.2+

Даже не подозревал о таком. Всегда плагин ставил.

Сравните кстати, с деактивированным плагином, будут ли те же замечания или они пропадут ?

Источник

Ответ не является допустимым ответом JSON.

Ошибка публикации. Ответ не является допустимым ответом JSON.

не могу сделать ни одной записи в блог

ошибка Elementor плагин

«Ошибка публикации. Ответ не является допустимым ответом JSON.»

Не хостинг, локальный сервер

Не могу корректно настроить

Что делать? Заранее спасибо.

Страница, с которой нужна помощь: [войдите, чтобы увидеть ссылку]

Инструменты — здоровье сайта

загляните, есть ли замечания там.

впрочем, по локальному хостингу может быть много нерешаемых и странных проблем, лучше использовать хостинг реальный

«загляните, есть ли замечания там.»

3 рекомендуемых улучшения

3 рекомендуемых улучшения

Одно или несколько рекомендуемых расширений отсутствуют
Производительность
Расширения PHP выполняют многие задачи на сервере для обеспечения работы вашего сайта. Обычно любые изменения в них производятся системным администратором сервера.

Команда хостинга WordPress поддерживает список требуемых и рекомендуемых расширений в этом руководстве (откроется в новой вкладке).

Внимание! Рекомендуемое расширение imagick не установлено или отключено.

Запланированное задание пропущено
Производительность

REST API выдал неожиданный результат
Производительность
REST API — один из способов коммуникации WordPress и других приложений с сервером. К примеру, экран редактора блоков использует его для отображения и сохранения ваших записей и страниц.

Запрос к REST API завершился с неожиданным результатом: (404) 404 Not Found

Not Found

The requested URL was not found on this server.

Источник

Как исправить ошибку обновления редактора WordPress

Приветствуем вас! Иногда при редактировании сообщения или страницы вы можете увидеть ошибку обновления или ошибку публикации в редакторе WordPress гутенберг. Эта ошибка не дает никаких подсказок, что делает ее особенно сложной для новичков. К счастью, есть несколько распространенных причин и обходных путей, которые могут помочь вам решить эту проблему, если вы с ней столкнетесь. Мы объясним, что вызывает эту проблему и как избежать этого в будущем.

Почему WordPress иногда не может обновлять или публиковать контент

По сути, WordPress иногда использует набор API (методов программирования), называемых REST API, для отправки и получения запросов к базе данных.

Если он не может отправлять и получать эти запросы, некоторые части вашего веб-сайта могут не работать. Сюда входит редактор блоков WordPress, который использует API для отправки запросов на обновление и публикации.

Почему WordPress не может использовать REST API?

Теперь вам может быть интересно, если я не вносил никаких изменений в свой веб-сайт, почему REST API перестал работать сам по себе? Существует ряд сценариев, которые могут помешать WordPress использовать REST API. Например, возможно, вы не подключены к интернету или потеряли связь.

Другие причины могут быть немного сложнее. Например, вы могли случайно изменить URL-адрес сайта, плагины могут быть причиной проблемы или сторонняя служба может блокировать вызовы API. Давайте посмотрим, как устранить и исправить ошибку обновления WordPress.

Шаг 1. Проверьте подключение к Интернету и URL-адрес сайта.

Наиболее частой причиной ошибки обновления в WordPress является потеря соединения Wi-Fi. Если ваш компьютер теряет подключение к интернету, когда вы пишете статью в блоге, WordPress не сможет сохранить ваши изменения.

Убедитесь, что вы подключены к инету, посетив другие веб-сайты в новой вкладке браузера. Если ваш интернет работает нормально, то следующее, что вам нужно проверить, — это настройка URL-адреса вашего сайта WordPress.

Просто перейдите на страницу «Настройки» — «Общие» и убедитесь, что параметры «Адрес сайта» и «Адрес WordPress» указаны правильно. Должны быть одинаковые URL-адреса в обоих полях.

Если настройки URL-адреса вашего сайта выглядят нормально, и вы подключены к интернету, вы можете перейти к дальнейшему устранению неполадок.

Шаг 2. Проверьте статус REST API с помощью WordPress Site Health

WordPress поставляется со встроенным инструментом работоспособности сайта, который показывает важную информацию о безопасности и производительности сайта.

Просто перейдите на страницу «Инструменты» — «Здоровье сайта» , чтобы просмотреть отчет. Если REST API не работает, вы увидите это в разделе рекомендуемых улучшений как «REST API обнаружил неожиданный результат» . У нас на тестовом сайте данной ошибки нет, но у вас она может быть.

Он также может показать вам некоторую отладочную информацию, которая может объяснить, что произошло, когда WordPress сделал вызов REST API. Изучение этого может дать вам некоторое представление о том, какой плагин или сторонняя служба могут вызывать проблему. Однако, если это не дает вам никакой подсказки, вы можете перейти к следующему шагу.

Шаг 3. Отключите все плагины WordPress

Если какой-то плагин WordPress вызывает некорректное поведение REST API, то самый простой способ выяснить это — деактивировать все плагины.

Вы можете перейти на страницу «Плагины» , установить флажок и нажать «Деактивировать» и «Применить» .

После этого вы можете перейти в редактор записи и попробовать обновить. Если ошибка обновления удалась, это означает, что причиной проблемы был один из ваших плагинов.

Теперь вы можете активировать свои плагины WordPress по одному и попытаться воспроизвести ошибку. Как только вы найдете плагин, вызывающий проблему, вы можете обратиться за поддержкой к автору плагина или найти альтернативный плагин.

Но, если отключение всех плагинов не привело к исчезновению ошибки, перейдите к следующему шагу.

Шаг 4. Проверьте службу брандмауэра веб-сайта

Если вы используете службу брандмауэра веб-сайта, такую как Sucuri или Cloudflare, то есть вероятность, что эти службы могут блокировать запросы REST API.

Это может произойти, если их фильтры брандмауэра сочтут ваш IP-адрес подозрительным. Они также могут блокировать запросы REST API, если ваш сайт подвергается атаке DDOS. Если вы используете Cloudflare, вы можете временно отключить Cloudflare, чтобы посмотреть, решит ли это вашу проблему.

Обычно вы найдете настройки Cloudflare в разделе «Домены» на панели управления хостингом. Если вы используете Sucuri, вы можете обратиться в их службу поддержки, и они могут внести ваш IP-адрес в белый список или сообщить, что вызывает проблему.

Плагины и службы брандмауэра являются наиболее частой причиной ошибки обновления. Однако, если вы все еще видите ошибку, вы можете сделать еще несколько вещей.

Шаг 5. Включите и просмотрите журнал отладки WordPress

WordPress поставляется со встроенной функцией для ведения журнала всех ошибок WordPress. Он не регистрирует ошибки REST API, но поможет вам узнать, есть ли другие проблемы, которые могут вызывать ошибку.

Просто добавьте следующие строки в свой файл wp-config.ph:

Не забудьте сохранить изменения и загрузить файл обратно на свой сервер. Теперь вы можете попробовать опубликовать или обновить сообщение в WordPress, чтобы воспроизвести ошибку.

После этого вы можете подключиться к своей учетной записи хостинга WordPress с помощью FTP-клиента и перейти в папку / wp-content / . Отсюда вы можете загрузить файл debug.log на свой компьютер.

Вы можете открыть файл отладки в текстовом редакторе, например, в блокноте. Он может содержать несколько ошибок, предупреждений или уведомлений, обнаруженных WordPress, когда вы работали со своим сайтом или, когда его посещал пользователь.

Если вы видите что-то, что указывает на файл плагина или темы, это может указать вам на ошибку. Затем вы можете упомянуть об этой ошибке, когда просите поддержки на форумах WordPress.org или у вашего хостинг-провайдера.

Шаг 6. Временно переключитесь на классический редактор WordPress

Временное решение этой ошибки — включить классический редактор. Это старый редактор WordPress, который не использует REST API для обновления и публикации контента.

Вы можете включить его, просто установив и активировав плагин Classic Editor. После активации вы можете просто отредактировать сообщение, над которым работали. Вы сможете сохранить и опубликовать его, не увидев сбоя обновления или ошибки публикации в WordPress.

Если все остальное не помогло, возможно, вам придется обратиться за поддержкой. Вы можете начать с прямого обращения к своему хостинг-провайдеру. У них есть доступ к журналам сервера и дополнительным инструментам. Это также может быть вызвано неправильно настроенным сервером или сбоями на их стороне. Ну что у нас на этом все. Всем пока!

Источник