Problem/Motivation

@todo

Proposed resolution

Only get the plugin definitions for plugins that can legitimately provide theming information.

Remaining tasks

See if this still passes tests.

User interface changes

None.

API changes

Would formalize that particular types of plugins can't provide theme information.

xhprof screenshots with before/after attached. You can see the many less plugin definitions retrieved, however the overall numbers don't seem to improve that much.

Comments

catch’s picture

Title: views_theme() gets 18 types of plugin definition, only needs four » views_theme() gets 19 types of plugin definition, only needs four
dawehner’s picture

Title: views_theme() gets 19 types of plugin definition, only needs four » views_theme() gets 19 types of plugin definition, only needs five

Here is a list of plugin types!:

    'access'  does not render anything
    'argument_default'  does not render anything
    'argument_validator'   does not render anything
    'cache'  does not render anything
    'display_extender  does not render anything
    'exposed_form' => does render something potentially
    'join'   does not render anything
    'pager' => 'plugin',
    'query'   does not render anything
    'row' => 'plugin',
    'style' => 'plugin',
    'wizard'  does not render anything

So we should add exposed forms.

catch’s picture

StatusFileSize
new903 bytes

Adding exposed forms.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Looks perfect now!

webchick’s picture

Makes sense. My only question would be if it makes sense to have some sort of special annotation for these so we could $plugins = Views::getPluginDefinitions('sometype'); (obviously pseudocode) versus a hard-coded list. Else it seems like we are preventing contrib from extending here (but maybe that is fine).

dawehner’s picture

Makes sense. My only question would be if it makes sense to have some sort of special annotation for these so we could $plugins = Views::getPluginDefinitions('sometype'); (obviously pseudocode) versus a hard-coded list. Else it seems like we are preventing contrib from extending here (but maybe that is fine).

Well, where would those annotations live? There is no formal definition of plugin types, beside the existence in the .services.yml file and the hardcoded list in \Drupal\views\Views

damiankloip’s picture

This looks good to me. This is not API changing/breaking either, as those PLUGIN types are the only ones we advertise a $theme property on (aside from the $register_theme property). All handlers are 'not allowed' anyway.

EDIT: didn't reload and just saw previous 2 comments, We could add a new method to the Views class. That is as good as it would get though I think. We don't really have a good way to get this info from the annotation metadata.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, thanks for considering. Let's get this in in the meantime then.

Committed and pushed to 8.0.x. Thanks!

  • webchick committed 9bd443f on 8.0.x
    Issue #2497113 by catch, dawehner: views_theme() gets 19 types of plugin...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.