This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Great! @srishakatux, just to clarify: according to German Wikipedia, Feb 5th, 12:00pm UTC means Sunday at noon UTC. I am asking as I see a lot of Wikimedia deadlines being set to midnight instead. So, is noon the correct interpretation?

@Mglaser hey, that's right! It's Sunday at noon UTC. As we'll start set up the voting process for these proposals later that day to make them ready for voting by Monday!

I see. Thanks for clarification @srishakatux !

This was the tenth most popular item in the Developer Wishlist results.

I'd go for one command line option per cache type, which can be freely combined. E.g. resetCache.php --wan --stash --minification.
As T156693: Complete documentation about different types of caching for extension developers points out our documentation about caching is not so great; assuming Manual:Caching does not miss anything important, the following cache layers should be supported:

• ObjectCache related
  • main WAN
  • local server
  • local cluster
• CDB
  • interwiki cache
  • localization cache
• parser cache
• ResourceLoader cache
  • minification
  • LESS
• file cache for page HTML
• reverse proxy (is it reasonable to support mass invalidation for this?)

@Tgr, sounds great! In addition, an option to reset all caches would also be nice.

In relation to T158149: Find an owner for top 10 Developer Wishlist 2017 proposals, I dare to ask: what is the current status? :)

For the use case of local development or small wikis, update.php is responsible for clearing all caches that are not automatically validated and/or relate to changes in code somehow. If something is not purged by that already, it should be reported and fixed separately.

For the use case of wanting to literally clear every cache that exists and is somehow connected to MediaWiki, I don't think such a script should exist. Depending on the systems you have in use, the relevant upstreams will be in a much better position to provide an easy way to purge those, and in a way that is documented and easy to find online (not in some MW-specific way that you'd need to be aware of). For example, if you need to clear MySQL caches, there's online docs for that. Same for Memcached. Same for Nginx. Etc.

And again if this is for some kind of developer environment, then presumably the abstraction for that should handle this instead. For example, when using MediaWiki docker, you'd tear that down and back up again and thus implicitly start fresh (except for MW core and installed plugins).

The only two caches I can think of off-hand that are owned fully by MW itself are the objectcache table (which update.php clears), and the HTMLFileCache directory (which is validated against wgCacheEpoch).

I think the use cases that people were thinking of during the wishlist are important, but unless they were written down, it will be hard to resolve. It is imho not a group of problems that should be solved together.