Bug Confirmed.

We need to decide on how best to handle this? I can add code into the articles.php model which will check if the plugin is enabled and if not, set an error notice and filter by a.id.

Or we refactor it and have it so that the plugin injects it's options into the list opposed to being hardcoded.

The only valid fix is to remove the plugin and move all of it into the component. Because the component has options that affect the models which cannot be extended/edited by plugins (query filters) without overloading the component classes, the only option for a consistently behaving system is to not have the plugin. There is already an open task for this for 4.0, cannot be done in 3.x.

So surely for the 3.x series we should have a notice output i.e:

We could not filter on this option because the Vote Plugin is disabled?

A component is not supposed to be aware of plugins. Otherwise it defeats the purpose of plugins. Sadly we have built a system where this separation of concerns is not respected.

I agree it's not supposed to be, In this scenario, we can either make the component check the plugin. Or leave an sql error bug in the core? Whilst I agree the first is not great, surely it's better than the latter? Given it's only there for 1/2 more release cycles?

Why can't the column be used if the plugin is disabled? Especially as the data is still present in the database. Seems like there is other bad coding already in place that should be addressed. Probably changing the search tools field generating the options to something that can be injected based on active plugins, or making it use existing plugin events to inject extra options. But not hardcoded. Just because something was done like crap before doesn't mean we keep accepting crap solutions. So sure there is a way to fix this without introducing more plugin specific checks, especially because the plugin could be replaced for some reason (I've done it because of changes needed to make a site render correctly).

At present the filter list is a type list with values of the sql filter. The model then finds this and applies it, it doesn't do any checking it just makes it filter by it. The ratings_count is added by the plugin to the filter query and when it is disabled it no longer exists.

I suppose you could remove the injection of the query and hardcode it into the component if we are going towards moving it into the core opposed to plugin based?

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18281

closed as having Pull Request #18283