[#37678] - API broken after upgrade (Unable to load router: api)
- Closed
- 30 Aug 2023
- Medium
- Build: 4.1.2
- # 37678
Steps to reproduce the issue
After upgrading from 3.x to 4.1.2, the api seems top be broken, returning an error 500 and "Unable to load router: api" - this is the case on multiple sites (in fact, all we upgraded so far) so no "freak accident".
web.config was upgraded to the shipped default one, so this can't be the error.
Please help, as this breaks functionality depending on the API such as deleting images.
Expected result
404 w / {"errors":[{"title":"Resource not found","code":404}]} (as seen on fresh install)
Actual result
500 w/ Unable to load router: api
System information (as much as possible)
IIS 8 / 9 with PHP 7.4 / 8.0 (multiple servers)
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
@pAnd0rASBG Please check the forum post linked in the previous comment and if it works for you, close this issue here. Thanks in advance.
| Labels |
Added:
Information Required
|
||
Hi,
We've got the same issue on J4.1.3 website (upgraded from 4.0.0) on Linux / Apache Server / PHP 7.4
It worked before the upgrade. We've compared files (with Beyond Compare) between a Joomla 4.1.3 fresh installation where the API is ok and the upgraded website and everything is the same except the extra files from third party extensions but this shouldn't interfere.
We've run the 4.1.3 update again on the website but it s not helping.
Something in the DB?
Well,
Looks like it finally came from a third party extension. Removing it fixed the API call.
Cheers
And what was that extension?
And what was that extension?
Sorry Brian, it was SEBLOD. Still in RC for J4, that would explain.
Sorry for the late reply - managed to fix it by now as well.
The Problem was 2-fold:
a) the "Unable to load router: api" when trying to access /api was caused by RSSEO
b) this one is noteworthy: not being able to delete images is caused by IIS' default behavior. When registering the fastcgi/php handler, IIS sets it by default only for GET, POST and PUT (this seems to be the case when using the web platform installer, the iis php extension and registering the handler manually respectively). Since deleting images is a DELETE request, IIS fails to call php, as it's nopt registered for DELETE Requests. The Handler needs to be changed manually to "allow all keywords".
| Labels |
Removed:
Information Required
|
||
Thank you for this information! Would you please open a new issue for your second hint? Then it will not be forgotten and we can close this one, where the title is now misleading.
@richard67 same issue but different caause. That one was caused by a host disabling it in apache. This one is that the default for IIS is to be disabled
@brianteeman I see .. thanks for clarification.
@pAnd0rASBG Do you have access to the IIS configuration so you can enable DELETE requests? Or is that something not in your hands?
Quy
- | Labels |
Added:
Information Required
|
||
jwaisner
- | Priority | Critical | ⇒ | Medium |
| Labels |
Added:
bug
|
||
Closing as the first part was a bug in seblod and the second part is a user sever configuration issue that has had no response for over a year
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-08-30 12:46:20 |
| Closed_By | ⇒ | brianteeman |
| Labels |
Removed:
Information Required
|
||
This must be an issue with the format of the request because the API authentication token and the API works all right in Joomla 4.1.2. There is no difference in the functionality of a Joomla 3.8.10 site that has been updated to Joomla 4.1.2.
An example of an API request posted to your forum topic at https://forum.joomla.org/viewtopic.php?f=812&t=993482.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37678.