'drush cr' should purge everything

Here is an initial version of a patch for this issue.

Basically this patch hooks into cache rebuilding (triggered either from admin performance page or from drush) and invalidates all the cache tags invalidated by drupal core.

Note that there is still work to be done here because we need to pass a purge processor for the invalidate method of 'purge.purgers' (which by the way, doesn't use that processor at all in it's body) but by default cron, lateruntime or purge ui block processor are not enabled.

So anyway, TODO: decide which processor to use in purge_rebuild() or propose another solution :)

After analysing the structure of the module a bit I think the best idea would be to create another submodule which when enabled will invalidate external caches on 'cache clear all' operations - this approach is consistent with how block, cron or late runtime processors are implemented.

So here is the patch doing that.

I don't think it should be a separate module, cache rebuild should purge everything by default, for me it is the expected behaviour. That is my five cents.

That works also. For that we will need to provide a plugin processor in the purge module because we need to pass a processor to the invalidate method or allow the invalidate method to work without a processor.

Purging external cache on a drush CR is new behavior that we should be VERY careful and fearful about. If I do a CR I would not expect that it would lower all my external caching shields. If this happened during a high-traffic event it could very easily result in web-servers getting overwhelmed by external traffic. If this is going to be added it should be opt-in.

Opt-out, if you ask me, because - what do you expect the default behavior to be? Clear all caches, for me sounds like, yeah clear all caches, not just drupal internal caches.

What about adding an optional argument something like drush cr --reversproxy for external purging ?

Like a side above, I think that then should be something like `drush cr --no-reversproxy-clear`

yes agree @MiSc. Anything that separates reverse proxy clear :)

what about the 'cache clear all' from the back-office performance page ?

I'm VERY reluctant about this folks, not because it isn't expected behavior of the CR command (in fact, it is) but simply because of real-world usage of this. People are already taking down sites right now here at Acquia by using CR without understanding its consequences, if people also take out their last line of defense (the external caches), then these self-inflicted downtimes will simply increase drastically. Really, people are assuming "drush cr" to be the natural successor to "drush cc all" without reading.

No, "educating people" is not a full argument against this, reality is a thing to consider too.

I'm not against the opt-in behavior of this kind of feature, but the opt-out case deserves much further debate including folks against before we can decide how to continue.

How about a second command drush cre / drush cache-rebuild-external? I think the upside of that is that its quite explicit and "in your face" and lets the user think twice about why he's calling a second command next to just CR.

Niels, LOVE that idea. It accomplishes the external clearing in a safe expected way. You know exactly when you are clearing the external caches.

Ok, I am convinced :-) drush cache-rebuild-external sounds like a good idea, and opt-in as option for the ui.

opt-in as option for the ui

are you thinking to some kind of BO config or a separate sub-module ?

I agree with the sentiment that `drush cr`, as well as the "clear all caches" button on the performance config page should NOT clear external caches. People are so used to running this command and they can easily take down a site if this is added.

Just wrote, tested and committed this:

commit 81a5d8c58800fe120aa90441d7184162ed9827d9 (HEAD -> 8.x-3.x, origin/8.x-3.x)
Date:   Sun Aug 13 14:00:09 2017 +0200

Renamed new Drush p-procsr commands --> p-processor (since the newest Drush no longer breaks its help overview).

Its basically a alias for drush p-invalidate everything and in the upcoming version of Drush (9+) it will align below the other of core's cache commands.

$ drush cache-rebuild-external
Invalidating everything will mass-clear potentially thousands of pages, which could temporarily make your site really slow as external caches will have to warm up again.

Are you really sure? (y/n): y
There is no purger loaded which means that you need a module enabled to provide a purger plugin to clear your external   [error]
cache or CDN.

$ drush pplsa
 Plugin        Label         Description                                                           
 acquia_purge  Acquia Cloud  Invalidates Varnish powered load balancers on your Acquia Cloud site. 

$ drush ppadd acquia_purge
The purger has been created!

$ drush cache-rebuild-external
Invalidating everything will mass-clear potentially thousands of pages, which could temporarily make your site really slow as external caches will have to warm up again.

Are you really sure? (y/n): y
Item invalidated successfully!

My client is asking me to port this functionality from 7 to 8 (it exists in 7 (see the varnish_vanish sandbox project), but with a 'button' to do what this drush command does. Not exactly easy as pie.

I've spent so far quite a bit of time on this.

hope this works, grabbing code from the purge_drush module... Thanks!
***BEGIN EDIT***
ah, just discovered some helpful api docs in the purge module README, double thanks!***END EDIT***