API call is wrongly Made to WP on reinstall WP #28
Comments
|
Are you able to dig in and see where that call is made? Is the call made through the WP_Http class or something else? We only rewrite rules that are passed through that class, so if they're made some other way (which wouldn't shock me) they won't be rewritten. |
|
Unfortunately I can’t see it in Query monitor when it’s updating and logs don’t save where the call is made from only calling Wp. Before when using main bransch it called AP but now in dev it’s calling WP. |
|
For testing. Set XXX as end point and try reinstall. It’s installing instead of giving a error message of not found.. |
|
Same issue with updating plugin. Is updating the plugin from Wp and not AP when testing dev bransch. But is making correct update check from |
|
Did anyone manage to get to the root of this. Does it have anything to do with plugins not being loaded when Wordpress is getting updated? |
|
I think that what is happening is one call is being made to us (to call the update info api) and then that info, passed through from WP, is directing them to download at .org. This is expected behavior. |
It you try #28 (comment) @sarah-savage |
|
Maybe I am missing something but #35 would not solve this issue. as it’s never triggering the rewrite and going to AP only to WP. To demonstrate it I was to change to a host that is not valid. Because if it was trigged it should give an error message and not going to WP. It worked before the refactoring in the old main… |
|
There is no place for us to trigger an error message in the workflow but we can make sure the API end points are genuine. The API calls are being made from a lot of different places and from cron jobs, we can’t tie all it up to a place in the UI to show those messages, atleast without a lot of custom work for each api call. But what we can easily do is to make sure the API end points do exists before we even save it and let the calls hit it. |
|
It’s not about the error message it’s about the AP is not called and WP is call instead wrongly. |
|
@ipajen Is this valid in the new version? |
|
@namithj The issue still exist. file is still be downloaded (not only GUI showing the WP URL) and reinstalling from WP. I am expecting it should try it from the AP/Host xxx. Or is there some hidden fallback that go WP if failed? `[2024-10-24 17:37:09] [STRING]: Default API Found :https://api.wordpress.org/plugins/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: API Rerouted to :https://xx/plugins/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: Default API Found :http://api.wordpress.org/plugins/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: API Rerouted to :http://xx/plugins/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: Default API Found :https://api.wordpress.org/themes/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: API Rerouted to :https://xx/themes/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: Default API Found :http://api.wordpress.org/themes/update-check/1.1/ [2024-10-24 17:37:09] [STRING]: API Rerouted to :http://xx/themes/update-check/1.1/ [2024-10-24 17:37:10] [STRING]: Default API Found :https://api.wordpress.org/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:10] [STRING]: API Rerouted to :https://xx/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:10] [STRING]: Default API Found :http://api.wordpress.org/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:10] [STRING]: API Rerouted to :http://xx/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:13] [STRING]: Default API Found :https://api.wordpress.org/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:13] [STRING]: API Rerouted to :https://xx/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:13] [STRING]: Default API Found :http://api.wordpress.org/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:13] [STRING]: API Rerouted to :http://xx/core/checksums/1.0/?version=6.6.2&locale=en_US [2024-10-24 17:37:19] [STRING]: Default API Found :https://api.wordpress.org/plugins/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: API Rerouted to :https://xx/plugins/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: Default API Found :http://api.wordpress.org/plugins/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: API Rerouted to :http://xx/plugins/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: Default API Found :https://api.wordpress.org/themes/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: API Rerouted to :https://xx/themes/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: Default API Found :http://api.wordpress.org/themes/update-check/1.1/ [2024-10-24 17:37:19] [STRING]: API Rerouted to :http://xx/themes/update-check/1.1/ ` |
|
Let’s keep this on hold till AspireCloud gets updated with next version. |
|
Agreed with @namithj lots of moving parts let's not jump into any particular solution yet. |
|
This will start working once AspireCloud starts serving its own local copies of files. |
asirota
added
question
|
Let's keep it open to confirm once it is working. |
Tested on dev
Excepted: an api call is made to AP trying to download WP (and in current state would fail).
Actual: an api call is made to WP.org and the file is downloaded and reinstal WP. no call to AP is made
The text was updated successfully, but these errors were encountered: