WordPress.org

Making WordPress.org

Opened 18 months ago

Last modified 8 months ago

#3107 new defect

Plugin Directory: Changelogs not updating on Rosetta plugin directories, Act II

Reported by: let me see... Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords: 2nd-opinion
Cc:

Description (last modified by SergeyBiryukov)

On WP MS German install, the changelog for plugin updates is almost always one version behind (today: Yoast 5.4 update available, changelog in my backend says 5.3.3 is latest)

Very similar problem to this ticket: #2750

Change History (7)

#1 @SergeyBiryukov
18 months ago

  • Description modified (diff)

This ticket was mentioned in Slack in #meta by sergey. View the logs.


18 months ago

#3 follow-up: @zodiac1978
18 months ago

@SergeyBiryukov Isn't the plugin details page in the WP backend cached locally? I see this very often too and had a short talk with @obenland on this topic. I am wondering because if I see there is an update I should see the correct changelog, but I see an old one. Not sure if this is a problem with the translated version, local cache or something else.

#4 in reply to: ↑ 3 ; follow-up: @SergeyBiryukov
18 months ago

Replying to zodiac1978:

Isn't the plugin details page in the WP backend cached locally?

The API request is performed by plugins_api() via install_plugin_information(), I don't see any caching there at a glance.

#5 in reply to: ↑ 4 @zodiac1978
17 months ago

Replying to SergeyBiryukov:

The API request is performed by plugins_api() via install_plugin_information(), I don't see any caching there at a glance.

Then what could be the reason for this behavior? I get a notice about a plugin update, click the details link to open the modal and get an old changelog info. If I switch to the page in the plugin directory there is the newest changelog info and sometimes the info is on local version of the plugin directory (and sometimes not).

I would expect to see the current information in my backend, if I get an update notice. If there is a cache it should be invalidated. If not, I have no clue what the reason of this issue can be ... any ideas?

#6 @swissspidy
17 months ago

Then what could be the reason for this behavior?

Caching on the API server I suppose.

#7 @obenland
8 months ago

Is there a current example we could use to troubleshoot?

Note: See TracTickets for help on using tickets.