Port modalframe API to Drupal 7

I'm glad to see there's interest in the modal frame concept. I opted for this solution because of the problems stated in your article, things related to AJAX loading, different stylesheets, scripts, DOM namespace, etc.

At a first sigh of the patch, a couple of comments:

1) I don't have a Drupal 7 site for testing your patch at hand. I'm curious to know if the PHP side still works in D7, as I was playing with the inners of the theme registry and FAPI to get an API as easy to use as possible.

2) If we wrap all the js code inside a function that gets jQuery as argument, where it is passed as $, then we don't need to use jQuery, but $ to access the jQuery object.

3) In regards to onBeforeUnload API... it would be nice to still keep this requirement. It helps to enhance the user experience when a form is submitted, as it can tell the parent window to hide the iframe and show the "loading" animation while the form is being processed. In fact, I could have coded the use of the onbeforeunload event directly in the code of Modal Frame module. But I opted to make the onBeforeUnload API a separate module as it provides a central place to deal with this event, where it's easy to avoid conflicts with other modules that may need it. While developing the Modal Frame module I added conditional code to check the API is really there, and it seems I forgot to remove that, so you found it's optional, but it's merely my fault. :P I believe, something like onBeforeUnload API would have to be part of jQuery itself.

If you want to see how Modal Frame API works on a complex situation, please take a look at this:

http://drupal.org/project/noderelationships (I expect to get it ready during next week, it's for D6 though)

On 1, hmm... ok, if the example module works, then I guess the tricky things related to theme registry and FAPI should work on every other scenario. That's good to know. :)

On 2, ok. I see what you mean. So... I could apply this pattern to the version for D6, so the differences between both are restricted to a minimum. After all, wrapping the code into anonymous functions that way is not so insane.

On 3, hmm... ok. I think I could live with onBeforeUnload API as a "recommended" module (I'll update the README and project page). Please, let me know if there's anything I can do to make it easy to port this module into D7 as well.

Well, later today I'll try to apply changes to the D6 versions of the module, and then I'll commit your patch for D7 UX. I'll update this issue when I'm ready.

Just wanted to mention this is taking a bit more time than expected because changing default width/height to 98% exposed a bug where it happens that the size of the dialog/iframe is not computed correctly. So I'm trying to find a way to fix this.

I'm also adding an example on how to edit a node on a modal dialog, so that we can also test this in D7.

BTW, we should also use iFrameWindow.jQuery in the unbindChild method, in parent.js.

I have already committed a few changes to the D6 branch, and I'm in the middle of creating the D7 brach. The changes between both would be minimal. I have to leave right now, but I'll continue later today...

Cheers

Well, I have already created a branch for D7 and committed the ported module, which is based on your patch above, plus the changes I introduced to try to better compute the dialog and frame sizes.

I'll take a look at your articles and the D7UX stuff when I have a bit more time. Please, let me know if there's anything I can do to help.

I am really interested in seeing this module ported to D7. I agree that it would be best to look at how best to integrate a D7 port with overlay module in core; however, I think it would be great to have a direct port while we wait ;-)

I have had a look at the current 7.x-1.x-dev shapshot, and in its current form doesn't work on D7. Yesterday I started working on converting current 6.x-1.7 to D7 -- I did not realize there was a 7.x branch already ;-). I have rewritten the modalframe_preprocess_hook() functions and modalframe_theme_registry_alter() to work with D7. Have also modified the page template which I have split into two which corresponds to page.tpl.php and html.tpl.php used by D7.

One thing I am struggling is how to convert the javascript files (parent.js and child.js) to D7. I have taken the code for these two files directly from the 7.x-1.x branch, but they do not seem to work. When I try to open a child the child.js script is exiting at this point in the script:

// If we cannot reach the parent window, then we have nothing else todo here.
  if (!self.isObject(parent.Drupal) || !self.isObject(parent.Drupal.modalFrame)) {
    return;
  }

This leads me to think that there is a problem in parent.js. Any ideas on how to convert these two scripts?

I new to drupal, I am working on new assignment in drupal, My task is to show popup on clicking the images, Popup contains Name, email and address, On click on submit button it should send a mail to admin of the site. As i am new to drupal, I dont know how to do that, I got some help from sites like install popup API in my system and add to in module, I am able to install but I am not able to access the Popup API in Modules, it show error like " This version is not compatible with Drupal 7.x and should be replaced.
Required by: Popups: Administration Links (disabled), Popups: Test Page (disabled)" this. Can any one help me. I am using Drupal 7.x and popup API is "6.x-2.0-beta0".

I have been working on this port to D7 and so far have got it working to the point where I one can now load pages into a modal frame. I have fixed several problems with the current 7.x branch including:

1. Modal Frame template files: I have split the original page template file into to files corresponding to the html.tpl.php and page.tpl.php files used by D7.
2. Preprocess functions: modified to make use of "$variables['theme_hook_suggestions']" instead of "$variables['template_files']"
3. jQuery: jQuery was proving somewhat problematic as there is a known bugs in jQuery 1.4.4 and 1.5.2 that are not compatible with parent.js and child.js scripts in Modal frame module. To solve this I have modified the module to use a downgraded version of jQuery (jQuery 1.3.2 and jQuery UI 1.7.4).
4. Examples module: I have created my own examples module which I have been using for internal testing purposes.

In its current form the module is still not considered usable, although I can now actually load the modal frame with content and close it using the toolbar button at the top of the modal frame. I am currently struggling with getting the modalframe_close_dialog() function to work.

function modalframe_close_dialog($args = NULL) {
  // Make sure this action is not processed more than once.
  if (isset($GLOBALS['modalframe_close_dialog'])) {
    return;
  }

  // Build the javascript settings that will close the modal frame on the
  // client side.
  $child_js_settings = array(
    'closeModal' => 1,
//    'statusMessages' => theme('status_messages', array()),
    'statusMessages' => '',
    'args' => (isset($args) && is_array($args) ? $args : array()),
  );
  drupal_add_js(array('modalFrameChild' => $child_js_settings), 'setting');

  // Tell Drupal's Form API that we are requested to close the modal dialog,
  // so we do not wish to perform redirections after submitted form has been
  // processed.
  $GLOBALS['modalframe_close_dialog'] = TRUE;
}

I have been trying, somewhat unsuccessfully, to debug it. It would appear that for whatever reason, the inserted javascript in the above code cannot be found be found by the Modal Frame object for child windows. The specific line where it is failing is where the script tests for "settings.closeModal" in which case closeModal is reported as 'undefined' (see below extract from file "child.js"). So I am assuming this is why the child window is not closing.

// If a form has been submitted successfully, then the server side script
    // may have decided to tell us the parent window to close the popup dialog.
    if (settings.closeModal) {
      parent.Drupal.modalFrame.bindChild(window, true);
      // Close the child window from a separate thread because the current
      // one is busy processing Drupal behaviors.
      setTimeout(function() { parent.Drupal.modalFrame.close(settings.args, settings.statusMessages); }, 1);
      return;
    }

I am really at a loss as to what is going on so figured now was a good time to ask for help. I would appreciate any suggestions. I created a patch of the changes I have made, but it appears not to include the new files I have added. So in addition, I am attaching a zipped version of the module.

Sorry but what's going on here? From reading this issue it appears a port was done 3 years ago, but never released. Then Begun ported it again?

I am trying to come to a decision whether to invest time in integrating with this module.

From the project page

Note for those interested in Drupal 7 support for this module: It seems this feature is being included in Drupal core itself. So, probably there will be no stable release of this module for Drupal 7 because it will be already there. :-D See: #517688: Initial D7UX admin overlay

According to the node revision log this statement was added in December 2009 as requested in #668540: Mix autoResize + autoFit options, add onOpen and customDialogOptions, and add doxygen comments to Drupal.modalFrame.open()

There is further discussion here #942166: Port Modal Frame API to D7?

My guess would be that a full Drupal 7 release/support in this project is unlikely because of the similar feature in Drupal 7 to do the admin thing.

I have not dug deeply into the overlay feature in core, but I was under the impression that it is not the same. I was already using Modal Frame API in a D6 custom module, and it worked so well, that I was hoping to make use of it again when I ported the module to D7 (hence I played with it a little to see what might be involved in porting Modal Frame API). What I would really like to know is, what are other people using in D7 as an iframe based replacement to Modal Frame API? It seems strange to me that there hasn't been more people supporting a D7 port.

I know ctools has a faux popup feature (non-iframe), but I too am a little lost as to what to use.

Interestingly the D7UX admin overlay was submitted by Gabor #517688: Initial D7UX admin overlay
Gabor started this issue that we're currently in only 4 weeks earlier to get a port going, so it looks like this issue turned into that one somewhat.

I can't find any instructions for using the D7 overlay. It seems to only accept paths that start with 'admin' ?

You can open non-admin pages in overlay by using hook_admin_paths(). One problem I see with overlay is that it is tied into the administration section. Some people have complained about poor performance when overlay is used and suggest disabling it. This will cause a problem if you want use modal frames in your module regardless of whether overlay is in use in the admin section.

Another thing is that I am not sure if overlay has the ability to perform program logic on modal events e.g. "on close". Perhaps it is there, but I haven't come across it or it is not well documented if it is. Would need to look at the API more closely. The thing I liked about Modal Frame API is that it was well documented and easy to implement.

That seems like misuse of the hook, as the hook defines administrative paths, but the page I want to popup is definitely not administrative.

Hey Begun you know D7 comes with jquery ui in a js library? I noticed you packaged your own version.
http://api.drupal.org/api/drupal/modules--system--system.module/function...

I was running into some js errors in the modal frame js files. After some research it appeared they may have been caused by a known bug in the version of jQuery shipped with D7. So I figured I would keep things simple, by first getting things working in D7 using the versions of jQuery known to work with Modal Frame. Once I got things up and running, I planned to look at upgrading the jQuery.

Unfortunately I haven't made it to that stage yet. I kind of got stuck along the way. For some reason the call to drupal_add_js(array('modalFrameChild' => $child_js_settings), 'setting'); in modalframe_close_dialog() just wont work. Everything else in modalframe_close_dialog() appears to be working as it should, just not drupal_add_js().

Thanks for all your work, Begun. I've been looking at the D7 branch and it seems to be a bit out of date, especially the js.

This patch is created against the 6.x-1.x branch which didn't require much work at all for D7. I'm using D7's jQuery 1.5.2 and jQuery UI 1.8.11.

It's very barebones, I haven't included your template file changes or preprocess functions changes. The only test I've done is to open a modal box within the theme by adding a call to modalframe_parent_js() to template.php and the necessary js to the theme's js file.

The sample module is removed.

The diff is for clarity, it leaves out the deleted files to only show what's changed.

Ok I wasn't aware CTools has its own modal dialog feature. There are some limitations with it, although there are moves to support jQuery UI modals as well: #1397370: Make modal.js use jQuery dialog

I really like the compatibility, flexibility and simplicity of ModalFrame API and Automodal. Is there still interest in D7 versions of these?

See also: #1469508: Automodal Drupal 7 Port

I've added the template files and relevant module changes from #12. This seems to work pretty well.

It still has the closeDialog problem Begun came across.

Again, this is against the 6.x-1.x branch.

Take 3. Updating the Drupal.behaviors bit fixes the closeDialog issue.

The example module from #12 seems to need $form_state['redirect'] = FALSE; in the submit handler (see modalframe_close_dialog() does not work on node edit).

function modalframe_example_form_submit($form, &$form_state) {
  $form_state['redirect'] = FALSE;
  modalframe_close_dialog();
}

The patch in #26 is against version 6 so this might be better as a 6 issue.

Suppose better to make a sanbox project or ask maintainer for 7.x-2.x branch

PS: Marked as duplicate #942166: Port Modal Frame API to D7?

Not keen to create a sandbox for an existing project . Would a 7.x-2.x branch help people test it? Would be handy to have some feedback.

Don't think it needs a 7.x-2.x branch as this is just a port of the 6.x-1.x branch. I think it would make most sense just to merge it with the existing 7.x-1.x branch. The fact that the patches created by imclean are based on the 6.x-.x branch doesn't really matter, as the current 7.x-1.x branch, as far as I can tell, is pretty much a clone of the 6.x-1.x branch anyway. It is not like we would be breaking the 7.x-1.x branch as it is currently unusable in its present state.

andypost, Begun: how did you go with the patch in #26?

@imclean
Sorry, but I have not tested the patch as of yet. In the end I switched to using Ctools modal in my module. When I get time I will try the patch on an earlier commit of my module which still implements Modal Frame API. Will let you know how it goes.

@imclean
I have tried out the patch in #26 and experienced no problems. I tested it using the official modal frame API examples module. I had to modify the examples module to work in Drupal 7. I have created a patch for the examples module for inclusion in the hopefully soon to be updated Modal Frame API 7.x branch ;-) In keeping with your patch, I have created the attached patch from the 6.x branch, but I guess we really should be rolling patches for the existing 7.x branch, otherwise things might start getting confusing.

Does anyone want to become the maintainer of the module? It seems like that might be necessary - see http://drupal.org/node/251466 for details on how to do that.

Attached is a patch that combines @imclean's work in #26 on porting the modalframe module and @Begun's work in #34 which ports the modalframe_example module as well.

I noticed only one problem: The toolbar and shortcut are shown in the modalframe. Other than that, everything is working great!

FYI, I just request to co-maintain modalframe: #2135175: Offering to co-maintain modalframe

And I recently became co-maintainer of automodal: #2135193: Offering to co-maintain automodal

I've committed the latest patch from imclean and Begun to the 7.x-1.x branch in 258faf9. We can continue working on fixing the remaining bugs off that branch. I'm actually going to commit a fix for the showing the Toolbar in a moment.