Modalframe is a great API used for many modules, but there is no way to alter the default settings of existing modal windows.
I found this problematic using existing modules with the modalframe API requirement. In my case one of them was the nodereference explorer module where the size and properties of open windows were locked in the application and I needed to define new sizes to fit the web design.

This patch intent to add a kind of alter for the modalframe settings, but as the settings and behavior of this module run mostly in the js part of the code there is not a direct translation of an _alter function. Thus, there is a hook function that can be called from any custom module that adds some overriding values that will be passed to the parent.js part of the module when it have the same url than in the hook. The modal frame properties that theoretically could be overrided would be the defined with the options.
I was able to make this work with width, height, autoFit and draggable.

This would be an example of how to use this override settings

/*
 * hook_modalframe_override_js
 */
function mymodule_modalframe_override_js(&$override_js) {
  $override_js['/noderelationships/search/place/field_image_reference']= array(
    'autoFit'   => FALSE,
    'draggable' => FALSE,
    'width'     => 400,
    'height'    => 400,
    //'customDialogOptions' => array('show' => 'fade', 'resizable' => FALSE, 'position' => 'right'), // that is not working
  );
  return $override_js;
}

(It should be possible to pass new values for the jQuery UI Dialog settings but I was unable to make any change to the existing ones, I think that the format of js array values passed with drupal_add_js(*,'setting') affects to that )

The most difficult part of this it is looking for the right url of the modalframe. You need to check the existing module code to find the right values, or see the url that your are clicking or executing when the modal window is open.

Of course this is an open proposal to extend the features of this fantastic module (thank you, by the way for your all so incredible modules).
I am using this in a devel server and it should be very useful for customizing any existing module that uses Modalframe API.

CommentFileSizeAuthor
#2 modalframe_override_js.patch1.25 KBjcmarco
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markus_petrux’s picture

Status: Needs review » Needs work

Given the fact that this API is being used by a lot more modules than I could have never imagined, I agree that such a feature could be useful to cover even more use cases. :)

Though, I think we would have to use a method to alter this settings in javascript land. Maybe, the Modal Frame API could use a function to build the settings object, and this function could be overridden by other modules. It could be implemented like the Drupal.theme() stuff. ¿?

jcmarco’s picture

Status: Needs work » Needs review
FileSize
1.25 KB

Damn! the patch was lost!

brenda003’s picture

Status: Needs review » Reviewed & tested by the community

I'm not sure the best method this should be implemented, but this patch and hook are working great.

markus_petrux’s picture

Status: Reviewed & tested by the community » Needs work

hmm... it seems to me my comment at #1 was missed here.

Let's say the page contains 2 different methods to open modal frames, implemented by different modules. They could now co-exist well. However, if we alter the settings for one of those implementation, how do we prevent the other implementation from using the altered settings?

jcmarco’s picture

Status: Needs work » Needs review

Because settings are defined by url. (that is the only way I found to define an alter)
If each module are adding settings for different url's then there were no collisions.

Of course if there are two modules adding alters to the same url, then it will happen the same that now with a form_alter, the module with higher weight win.

markus_petrux’s picture

Status: Needs review » Needs work

Oh. I see. However, it does not look obvious how to pass options. There's a critical dependency on how these options have to be handled that it seems to me it could generate hard to debug situations when different modules use this hook in different ways.

I think we could be more confortable with something like the following mini-patch applied to modalframe/js/parent.js:

   // Build the modal frame options structure.
   self.options = {
     url: options.url,
     width: options.width,
     height: options.height,
     autoFit: (options.autoFit == undefined || options.autoFit),
     draggable: (options.draggable == undefined || options.draggable),
     onOpen: options.onOpen,
     onLoad: options.onLoad,
     onSubmit: options.onSubmit,
     customDialogOptions: options.customDialogOptions
   };
+
+  // Allow external modules to alter the modal frame options.
+  $(window).trigger('modalFrameOptionsAlter', [self.options]);

   // Create the dialog and related DOM elements.
   self.create();

Now, any module could do the following in its own javascript file sent to the parent window:

  // Implementation of the modalFrameOptionsAlter event.
  $(window).bind('modalFrameOptionsAlter', function(options) {
    // Check the URL passed via modal frame options to find the one
    // we are interested in.
    if (/regexp-pattern/.test(options.url)) {
      // Alter the modal frame options to suit our needs.
      options.foo = 'bar';
    }
  });
aufumy’s picture

I find the patch in #2 more useful for my case then #6.

However, having both patches applied might be fine as well.

My use case is that I want to alter noderelationships behaviour in my custom module.

So the likelihood that another custom module is altering noderelationships behaviour is small to negligible in my case.

Michsk’s picture

i would personally prefer a global overwrite option, to keep the overall feeling the same. And of course a option for a module to define it's own style but that again could be overwritten by the global options.

liquidcms’s picture

for my $0.02 worth.. i prefer a hook since i would rather work in php than js.

tried patch in #2 and it applied fine; but couldn't sort out which url to add; plus i can see this will be a pain as i have many places i use popups to edit... so would need to figure out url for each and add many many entries.

possibly, at very least.. an overall site config for maxWidth and maybe max Height (although i think width is more important of the 2) wouldn't be a bad idea.. and one that accepts % or px?

Alex Andrascu’s picture

I'm really looking forward to see this one implemented as a hook too.
+1

slucas’s picture

Hello,

I've look at your example implemention of the #2 new hook.
I've patched modal frame module with #2.
I want to use it on some of noderelationship module edit field.
But I don't know where to find the url, as it's not a real page and I don't know where it is in the node relationship module

function archiref_form_modalframe_override_js(&$override_js) {
$override_js['/noderelationships/search/place/field_image_reference']= array(
'autoFit' => FALSE,
.....

slucas’s picture

I've found solution to my question
look at the $GLOBALS variable
but now the second problem is when there is nid in the url how do I adress all nids ? with one alteration

dsnopek’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes

I agree with @markus_petrux: this should be in Javascript. Automodal does a Javascript hook-like-thing. We could probably reuse the same pattern that's used there. Since this is a new feature and there isn't a satisfactory patch, let's address it in the Drupal 7 version first.