CP 3.0 Nested Custom Widget Deployment Bug

In CP Framework Version 3.0, nested widgets behave differently depending on whether you are in development mode or staging/production.

The Handy Feature

Customer Portal has nice feature that allows you to extend an existing standard widget, and if you name it the same as the standard widget, it will automatically be used in place of the standard widget across all CP pages. For instance, if I extended the standard/input/TextInput widget and named it custom/input/TextInput, everywhere on the CP pages where input/TextInput was referenced, it would automatically use my new custom widget. There has always been a bit of controversy over this (as it could lead to unintended side-effects in unexpected places, for novices), but I have always been a proponent because it is a powerful and handy feature, as long as you are careful.

The Nasty Bug

In CP 3.0 an interesting bug was introduced. When overriding a standard widget in this way, if another widget nests this widget inside of itself, strange behavior occurs depending on which environment you are in. So, as in the scenario above, I overrode the input/TextInput, but know that the input/FormInput widget contains a nested version of this widget inside of it's view. So what happens here? You'd expect that the input/FormInput widget would use the custom input/TextInput widget I created naturally, as it used to in CP2 and everywhere else in the framework. Test it out in development mode, and it works great! Handy feature, right?

You deploy to staging for final tests and, bam!, your custom functionality doesn't work anymore. Somewhere in the optimization and deployment process, the parent input/FormInput widget incorrectly nests the standard version of the input/TextInput widget, rather than your custom one.

The Recommendation

I'm sad to say, as much as I love the ability to override standard widgets, because of this bug I highly recommend not overriding standard widgets. Use a unique name or namespace for your widgets, even if you want to override all text inputs in the framework. For instance, name your new text input widget custom/input/AdvancedTextInput or something similar. This will require you to create a custom version of the input/FormInput widget, but at least you will have full control and be able to explicitly state whether to use the standard or custom nested widgets.

Categories : 

Zircon - This is a contributing Drupal Theme
Design by WeebPal.