Disable/Destroy methods

[Wes Turner-Harris]

I'll try to add this in a pull request, but essentially from a development perspective, there should be a way to destroy and/or disable the colorpicker. If the colorpicker is instantiated on an input with a disabled property, the button should be disabled, which could be re-enabled by changing the input's disabled property and/or using a dedicated method of $.wpColorPicker.

[Matt Wiebe]

Hey Wes - this repo is exclusively for Iris, which wpColorPicker uses. What you're describing belongs in a core trac ticket.

Your points are good, although listening for changes to the disabled property on the input itself isn't feasible since MutationObserver events are only supported in IE 11. But, a method to dis/enable the wpColorPicker makes sense.

Outline your use case in Core Trac and we'll see. If you add a patch, there's a much better chance of it happening. :)

[Diosney]

I think that what @wturnerharris says is valid too for Iris, in case one developer wants to use it directly with its wpColorPicker wrapper.

Any chances this land directly into Iris?

[Matt Wiebe]

Iris already has disable and destroy methods because it's a jQuery UI widget. See http://api.jqueryui.com/jQuery.widget/ for more.

[Diosney]

Yes, indeed, but in some widgets, that is not good enough. In a group of them one have to overide those methods with custom ones in order to sanitize the HTML the widget build around the element, clear the events and so.

I really don' t not if Iris falls in the category of not need to do that.

For instance, I'm pretty sure wpColorPicker needs to overide them, since they wrap the original input in a bunch of tags, not so sure for Iris.

[Matt Wiebe]

Please go up and read my original reply - this is not the place for wpColorPicker discussions.

[Diosney]

@mattwiebe It seems that you misunderstood me or I didn't express myself correctly. Sorry for the last if it was the case.

I only used the wpColorPicker mention as an example on why a custom destroy method is needed.

I will restrict myself to speak only about Iris from now on.

The following is just a simple example to explain my point.

I just checked https://github.com/Automattic/Iris/blob/master/src/iris.js and didn't found a destroy method but did found the followind line:

$( '<style id="iris-css">' + _css + '</style>' ).appendTo( 'head' );

So, if I call .iris('destroy'), what will be really called is the default widget factory destroy method, which is good for a lot of reasons but it will never remove the just added <style> since it isn't aware of it. That is what I meant in my previous comment.

So, it is very likely (I'm not really sure, that is why I'm asking you) that Iris will need to override the widget factory destroy method in order to clean all the custom things it puts in the DOM.

[Matt Wiebe]

Removing the global style is tricky since any subsequently instantiated widgets would depend on it. destroy should just remove a particular instance and leave the possibility of new instances.

If this is a priority for you, please do send in a pull request and I'll review it.

[Diosney]

Nevermind, I solved the issue with another wayaround.

By the way, almost all JS widgets/plugins/addons around there solves this issue by letting the developer to include two files separatelly, one for the .js and another one for the global styles .css, that way all remains under control.

So, if the plugin have to insert some styles, that are controlled by the global included stylesheet or by inserting them inline in the element, so, in both cases one can effectivelly clean up all the inserted styles/events.