First up, thanks for such a great module! Along with automodal and a few other helpers we're finding all kinds of uses for it.
We're wanting to do some custom themeing based on the selector. When using the dialogClass option within customDialogOptions, it overrides the required dialogClass: 'modalframe', causing the dialog to freeze on "Loading...".
Looking at parent.js, this overriding is by design:
// Allow external scripts to override the default jQuery UI Dialog options.
$.extend(dialogOptions, self.options.customDialogOptions);
This is very helpful for the most part, but this being the modalframe API module, would we need to override this class?
Getting around it is easy enough, just add modalframe to the override:
dialogClass: 'modalframe custom-class'
Another option would be to preserve the modalframe class, if it is actually a required class. Adding something like this before the above code seems to do the trick:
if (typeof self.options.customDialogOptions !== 'undefined') {
if (typeof self.options.customDialogOptions.dialogClass !== 'undefined') {
self.options.customDialogOptions.dialogClass = dialogOptions.dialogClass + ' ' + self.options.customDialogOptions.dialogClass;
}
}
If there is a need to override the modalframe class then the workaround isn't too painful, just a note in the docs would be enough.
Comments
Comment #1
dsnopekI agree that this is a bug and should be fixed - user supplied options shouldn't remove ones that modalframe requires. Let's address this in the Drupal 7 version first!