trac nginx cache stuck in updating state

The nginx cache for https://core.trac.wordpress.org/ticket/54504 appears to be stuck in an updating state, with 2-day stale content being served.

This isn’t critical, but a sign of an nginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/. configuration change being needed I guess, or TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. is crashing on an unauthenticated request to that specific ticket consistently which seems unlikely.

$ curl -Is https://core.trac.wordpress.org/ticket/54504 | grep x-nc
x-nc: UPDATING

In the above example, Comments 94-96 are not visible in the cached response (ie. a logged out incognito request), but are for an authenticated user.

Unknown if this affects many URLs, low priority as it seems likely a rare occurence.

#trac #nginx #cache #prio3

Clear codex cache & lower cache TTL?

Per https://meta.trac.wordpress.org/ticket/6168 some codex pages have a cached header HTML + CSS which are incompatible with one another, causing a display mismatch.

While we’re migrating away from the Codex, it appears likely to remain for some time.

Can we please
1. Flush the codex cache
2. Lower the cache TTL, perhaps to a week or two, to avoid the need for future system requests?

#codex #cache #prio1

Seeing some problems with the theme prev…

Seeing some problems with the theme previews on /extend. Seems that there’s some kind of server-side caching of files going on and updates aren’t showing in the previewer properly. Not sure when it started.

Example: Minimal Georgia is at version 1.3.

http://wp-themes.com/wp-content/themes/minimal-georgia/style.css shows version 1.2.

http://wp-themes.com/wp-content/themes/minimal-georgia/style.css?foo shows version 1.3.

Is there some good way to invalidate the cache, given that we can’t really modify the themes themselves to add versioning information to the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org? I suppose you could put in some kind of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to use output caching to look for *.css and such, but that seems haphazard and weird.

I’m really not sure that the wp-themes.com domain should be doing that kind of server-side caching anyway.

#cache, #extend, #themes, #wp-themes-com