See #12331

I tried decoupling the voting plugin from being hardcoded into com_content but after adding the voting filters/ordering options into 3.7 at this point the only option I think there is for this is to integrate the plugin fully into the component and drop the plugin.

I was wondering if we could useif (JPluginHelper::isEnabled('content', 'vote')) in some way

Not without creating a bunch of custom fields and potentially extending the search tools logic in com_content basically. JForm has no way to conditionally show fields based on a plugin (which is why I originally tried doing #12516 but that's not practical anymore without conceding that we add query manipulation events).

So it can conditionally show values but not fields?

showon is purely based on UI state in the active form. For what you're hinting at, we need a mechanism to basically say "if X extension is disabled, remove field".

Either way, while it might be a nice to have feature, it's not really addressing the "right" issue. The plugin and component are tightly coupled and there isn't a way to separate the plugin's features from the component now.

There are two action points here:

1. Drop the plugin, make voting part of com_content in full. At this point it's really just shuffling around a couple of layouts and integrating the conditional logic into the com_content layouts natively versus using plugins.
2. Determine if it's feasible to expand JForm to include a "conditionally show field based on extension state" functionality and if so incorporate it.

No I am talking about the requires value in the xml

<option value="1" requires="vote">JSHOW</option>
<option value="0" requires="vote">JHIDE</option>

When vote plugin is disabled it results in neither of those options displaying anything in the select - so I was wondering if when there are no values in the select we can as a result change the message from "seletc an option" to "plugin disabled.

I didnt realise that this was something new in 3.7 and only used here - so I am going to close it as not worth the effort to resolve

The plugin is hardcoded to com_content (see https://github.com/joomla/joomla-cms/blob/staging/plugins/content/vote/vote.php#L110) only.
Honestly, that vote function should be implemented into com_content if it's only supposed to be working in com_content.
Or we open the plugin so it works with all content types, but then we should remove the options in com_content.

Or we open the plugin so it works with all content types, but then we should remove the options in com_content.

We can't do that anymore because 3.7 adds support for filtering items based on votes/ratings. Without query manipulation events or overloading the com_content MVC from the plugin, the only option now is as I said above (and what my other issue is now focused on), just moving voting into the component completely and killing the plugin.

FWIW we've got the same problem of plugins adding functionality only into com_content where they really should just be native features of the component with other plugins too (page navigation is an absolute certainty, page break is com_content only but kinda "fits" the plugin approach).

Agreed on the other two as well.

Maybe the "content" plugin group was once meant to be only for com_content, then it has made sense to have those plugins. But today that group is used by most extensions and we should not have any component specific stuff in there.
If there is hardcoding in a plugin to specific component(s), then it is done wrong.