Problem/Motivation
Currently, Display plugins have a getStyleType() method. This is used to filter style and row plugins by a type specified by this method. So if the type is 'data', only plugins with either no 'type' or a type of 'data' will be listed. (This has been something I've wanted to add to views in 7.x-3.x but let's just add it here first. Then other plugins, like access, cache, exposed_form plugins etc.. can also use this.)
An example of this working in its current form is for the REST Export display plugin; This declares a type of 'data', the serializer plugin (and row plugins) have this declared in their plugin definition, so on they are available when using that display.
Currently, in most cases, Views displays an unfiltered plugin list E.g. access plugins, which results in plugins being listed in contexts where they should not be used. For example, admin_views in D7 has a custom access plugin that only really works when using the system display type. However, there is no way to filter access plugins. So the system display shows all types of access plugins, and the admin views access callback is available on all other display types.
Proposed resolution
Use the existing method more consistently so that [example].
Details
- Rename the getStyleType() method to getDisplayType(), I think this makes more sense.
- Change the logic slightly in views_fetch_plugin_names() to check if 'type' is set.
- Pass this method to more views_fetch_plugin_names() calls to filter plugins.
Remaining tasks
Fix it.
User interface changes
More finely filtered plugin listings in certain cases.
API changes
Changed method name: getStyleType() => getDisplayType().
More flexibility for plugins and their definitions (in the UI).
Initial patch to get things moving and test the water attached.
Attachment | Size | Status | Test result | Operations |
---|---|---|---|---|
vdc.getDisplayType.patch | 10.37 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] 54,096 pass(es), 9 fail(s), and 1 exception(s). | View details | Re-test |