1. Users have to enable display extenders under the scary 'Advanced' settings page in order for them to work. If we convert extenders to drupal_alters() they can be self-contained in a module which can easily be turned off and on.
2. It requires a class/class registry in order to work.
3. Everything a display extender is doing is essentially an alter of each function inside the views display plugin.
4. We already have a conflict of parameters (PHP 5.3 warning) between views_plugin_display::option_definition and views_plugin_display_extenders::option_definition (which the latter is an alter...sensing a pattern here?).

I propose that we remove the display extender class and just replace them with calls to drupal_alter('views_plugin_display_[function]'). Using the class system when we have the perfectly valid method to perform alters in core seems like an over-complication.

I would assign this to dereine for comment since he was the lead in putting the display extenders into Views 3 but I don't have the permissions to.

Comments

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

In addition:
5. Disable a module that provides a display extender and you suddenly get a fatal error since views_plugin_display::construct() still tries to load it. This will not happen when using hooks and drupal_alter().

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Issue tags: +Metatags

Tagging since this affects the Metatags module.

bojanz’s picture

bojanz CreditAttribution: bojanz commented
Assigned: Unassigned » dawehner

Assigning to dereine.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Assigned: dawehner » merlinofchaos

I'm not opposite to convert it to drupal_alters, but this should really merlinofchaos decide. So assigned him.

Here are some oppinions why a plugin is not that bad.

Users have to enable display extenders under the scary 'Advanced' settings page in order for them to work.

Perhaps metatags module could enable it by in install/update hooks.

 If we convert extenders to drupal_alters() they can be self-contained in a module which can easily be turned off and on.

Does really everything has to be a module which from it's functionality is more like a plugin, from the sight of crells definition.
Why is the advanced tab scary? Extending displays are somehow an advanced feature.

It requires a class/class registry in order to work.

Which is actually a good thing, because people which are familiar with extending views will probably understand display extenders
as just another kind of plugin.

I'm not sure whether one additional class per view is really that hard compared to all other things which are runned at the same time.

Perhaps there are some problems with documentation how to write a display extender plugin.

 Everything a display extender is doing is essentially an alter of each function inside the views display plugin.

Yes that's more or less true, but the dispaly extending "system" was written with decorators in mind, so this is "by design" :)

 We already have a conflict of parameters (PHP 5.3 warning) between views_plugin_display::option_definition and views_plugin_display_extenders::option_definition (which the latter is an alter...sensing a pattern here?).

php_string--

Disable a module that provides a display extender and you suddenly get a fatal error since views_plugin_display::construct() still tries to load it. This will not happen when using hooks and drupal_alter().

Oh. This is certainly a bug which has to be fixed!

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Short point is that making a class to extend the behavior of another class without being able to actually extend the parent class is kinda wrong in an OOP standpoint and more complicated than just simple altering.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

I had also encountered WSOD errors in views_plugin_display::destroy() that I could not temporarily fix unlike construct() when a display extender was disabled.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Some follow-issues

* #1279352: Document how to use display extenders
* #1279344: WSOD if display extender is used but module is disabled

Feel free to create some others as well.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

#1279202: Make enabling display extenders easier for end-users
#1279182: Disabling a module with a display extender causes WSOD errors

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Also
#1281698: PHP strict warning: Declaration of views_plugins_display_extender::option_definition() does not match its parent class

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Active » Closed (won't fix)

Beside the open bugs, i think this issue will not be fixed.

eabquina’s picture

eabquina CreditAttribution: eabquina as a volunteer commented
Issue summary: View changes

I encounter the exact same issue.What could be a workaround to avoid this?

The site seems to be well, its just that the cache clear wont work wihtout any error.

EDIT: I just re-enabled the module that i removed and all works fine now.