Dispatch the CACHE_CLEAR_CONTENT events from the Legacy

[Plopix]

It seems that the CACHE_CLEAR_CONTENT event is not trigger from the legacy Bridge.
https://doc.ez.no/display/EZP/Smart+HttpCache+clearing

The configuration mapper calls purge
https://github.com/ezsystems/LegacyBridge/blob/master/bundle/LegacyMapper/Configuration.php#L205

And the purge does not dispatch the events:
https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/MVC/Symfony/Cache/Http/InstantCachePurger.php#L54
Note sure about the if ($locationId != 1) but seems needed.

Let me kow!

[Plopix]

Ok after few other tests it is prob not the good way to do it for 2 reasons:

• first in this state the purge could be done several times because the cacheItems array is already full of node_id computed by the SmartViewCache legacy (could be fixed easily by calling the dispatch in the method)
• But there is another issue, actually the RelatedLocationsListener does some queries in the DB, and it crashed when the anonymous does not have the permissions to read. In my use case, it failed here
  https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/MVC/Symfony/Cache/Http/EventListener/RelatedLocationsListener.php#L54
  The eZ Repository user is anonymous, and it does not have the permission to read a version.

It is a purely bridge issue, any idea @bdunogier @andrerom @lolautruche @emodric ?

[andrerom]

There are other issue around, so actually the cache clearing system is kind of broken, it assume content still exists, which is not the case when you delete/trash it. So recently been investigating doing it differently and/or deprecating that system.

Also the reason legacy bridge uses purge is that it is supposed to triggered by cache clearing events in legacy that has already resolved affected nodes.

---

So in summary: @Plopix better if you describe the issue you have, as this does not seem like the right approach.