Add alter hook for cached plugin definitions

Just call to the getDefinitions() method of your plugin manager and then add a custom alter for your scenario in YOUR code. There shouldn't need to be one of these for run time. Filtering available plugins is a separate problem from finding the available plugins, and you're kind of conflating the two ideas here.

Eclipse

I didn't say you needed to override the managers, I said your UI should be responsible for the filtering.

$definitions = $manager->getDefinitions();
$definitions = $this->filterDefinitionsOnSomeCriteria($definitions);
return $definitions;

You can call to the manager yourself, you can override UIs that core or contrib provides, you can filter these definitions HOWEVER you like. You can alter (through existing methods) the $definitions array itself and append criteria of your own choosing to filter on later, you can do a GREAT many things to customize how a specific manager's plugins are treated. I don't see any need for a runtime alter at some generic level of the system. If you wanted to add a runtime alter to your specific use case, any of the above-mentioned approaches are likely to be helpful in that regard.

Eclipse

Instead of telling me how impossible this is, why don't you give the example you're dealing with? That's likely a way more constructive use of our time.

Eclipse

I'm a bit confused by this issue and the tone does make it a bit hard to follow as well.

That said, if I understand the requirement described in #3, you're talking about building a UI where you could see a list of all plugins for the type, then you could turn them on and off with checkboxes. Then every where else, whenever the plugins are listed or used, the disabled plugins would not show as if they don't exist.

I think the hardest thing described about the process in #3 doesn't really have anything to do with caching. Just clear the cache for that particular plugin definition when you submit the form and you're done, plugins don't show up. The hard part would be building a path around your filtering so you get the unfiltered list on the management form.

So setting aside that example and addressing the concept, by definition of how caching works, the reason you'd want to filter(or expand) the list outside of the cached values would be because your filter doesn't align with the cache context. For example if you filtered per user but the cache was site wide or if you wanted to filter per page but the cache was per user. Is that what you're asking for and could you help us understand how that would be useful?

Yeah, I intend on doing exactly that with blocks for panelizer integration eventually, and it just means that I'll be storing a separate config object that my UI will do an array_intersect on before displaying plugins. That won't make it disappear for core, but if I wanted it to, I could hijack core's block placement UI and make it respect the same config object(s). I'm still not sure I see a problem here.

Eclipse

So it sounds like you're a bit of two minds about what you need, I'll try to illustrate the approach I'd take, and maybe you can extrapolate out something that will work for you.

Field on an entity:
If you have a custom field type that shows a list of plugins and allows plugins to be turned on or off for use at say... run time of that entity being rendered, I could see you wanting to limit the list from one field configuration to the next. As you might have already guessed, I'd be saving the available plugin information into the config entity that represents the field config, which the field will get during edit and render time which will allow you to display plugins configured to be available vs all plugins. This would also allow you to store which plugins the content author wanted to have run in the field's storage, so I think we covered all the bases.

Do you have a custom plugin type for what you're doing? or is this for some pre-existing plugin type? I ask because there are plugin managers that do filter the list of available plugin definitions, but it's by some knowable set of criteria and it's a filter (not an alteration of the cache). Check out \Drupal\Core\Plugin\Context\ContextAwarePluginManagerTrait which is used by both the BlockManager and the ConditionManager (since those are context aware plugin managers). This might give you some additional ideas for more how to affect your available plugin lists.

Eclipse

So, since you yourself seem to have come to the conclusion that an alter is not going to solve your problem, I'm closing this. All I can tell you is that it's pretty easy to build filters of the available plugins. It might just mean you have to take over some controllers or something along those lines.

Eclipse