Error 404 – rest_no_route

Hi @janvitos,

Yes, it looks like the URL is not registered through the WP API for some reason. I wrote something here about it: https://meowapps.com/debugging-wordpress/#Issues_related_to_the_Rest_API. It’s not very complete yet, but it’s the issues I encountered until now, and how to solve them. If it doesn’t work for you, could you contact me directly? Here: https://meowapps.com/contact. I will definitely make it work for you ??

Hi @tigroumeow,

Indeed, I’ve tried the steps mentioned at that URL (Issues related to the Rest API), but it didn’t solve my problem.

I also tried uninstalling / deleting and reinstalling the plugin but to no avail.

I will contact you through your site, thanks.

Hi @tigroumeow,

I’m seeing that the failing REST API requests seem to be made using the GET method:

Request URL: https://www.website.com/wp-json/media-cleaner/v1/update_option/
Request Method: GET
Status Code: 404

But when digging into the rest.php file, I see that the only allowed method for the failing registered routes is POST. Could this be the issue?

For instance, I see that the route all_settings is registered with the GET method:

register_rest_route( $this->namespace, '/all_settings', array(
	'methods' => 'GET',
	'callback' => array( $this, 'rest_all_settings' ),
) );

And calls to this route are working fine:

Request URL: https://www.ipnoze.com/wp-json/media-cleaner/v1/all_settings/
Request Method: GET
Status Code: 200 

Just my two cents.

• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.

So I got the update_option route working!

To do so, I had to add “GET” as one of the methods in rest.php like so:

register_rest_route( $this->namespace, '/update_option', array(
	'methods' => 'GET, POST',
	'callback' => array( $this, 'rest_update_option' )
) );

After, it still didn’t work because there was a 301 redirect on the POST request that got rid of all the POST parameters. My web server adds a trailing slash to all URLs, so if there’s no trailing slash, like it was originally in index.js, then there’s a 301 redirect to the URL with a slash. I think this should definitely be taken in consideration in your plugin as many websites add a trailing slash at the end of URLs.

To fix that, I had to edit index.js and modify the /update_option route and change all occurrences to /update_option/ (added a trailing slash to the path).

Now I can modify plugin options as they are saved properly without throwing any errors. I might try and get all the other routes working to get the plugin fully functionnal again.

I’ll be happy to further debug should you need more help.

Thanks.

• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.
• This reply was modified 4 years, 2 months ago by janvitos.

Hi,

This is a big problem ?? I would love to fix that issue in my plugin, but it seems your server is doing something it shouldn’t.

1. This is not a GET request, this is absolutely a POST request. Arguments are written in the body of the request, so they can’t be converted to GET. Also, the plugin is using POST to list entries and so on, so anyway, POST needs to be “supported”.

2. One rule of the REST API (that is not specific to WordPress) is to not use a trailing slash on the API endpoints. So in this case, it seems your server is forcing that too ??

Besides Media Cleaner, the issue will happen with a lot more plugins, or even with WordPress Core itself (I am not sure where they are using the REST API right now, maybe just for Gutenberg)

Basically, I think the issue should be fixed on your server, otherwise you will always try to fix plugins, and one day WordPress itself ??

Thanks for letting me know about the trailing slash and the REST API requirements.

I will try and debug the trailing slash issue because that seems to be the probable cause of the problem.

No problem! Got me curious actually, and I admit, I had to double-check myself about those rules ??

Please let us know what you find, and maybe why those redirections were set up. It could be helpful for others to know. Cheers!

Well you’re the genius!

A while ago, I had manually setup a redirect from no trailing slash to trailing slash in my web server config, not knowing WordPress already does this automatically with permalinks.

So I removed the manual redirect from the config and your plugin is working like a charm again.

And I’m quite happy about fixing the trailing slash issue, because as you said, it probably would have caused me headaches in the future as more and more plugin developers start using the REST API.

Sorry for using up your precious time and thanks for helping out until the end.

You are really welcome! And thanks for the review you just wrote, this is really nice for you, I really appreciate it. It’s such a pleasure to help ??