From : http://drupal.org/node/1310932#comment-5235078

Apply the patch, replace modal.js with the provided file (the changes are way to big to make a patch useful) and enjoy your jQuery modal dialog. I played around with panels and it looks like it's working pretty well :)

There are a couple of changes, lots of events are fired now:

  • $(window).bind('modalBeforeCreate', function (event, modalDOMElement, dialogOptions) {}): Allow access to the DOM element and dialog settings before anything is created.
  • $(window).bind('modalAfterCreate', function (event, modalDOMElement, dialogOptions) {}): we can actually access $(modal).dialog() to change other things
  • $(modal).bind('loadStart'): this event is triggered just before the AJAX call, DOM inside the modal is untouched
  • $(modal).bind('load'): Drupal.detachBehaviors was called for the content of modal and all content was emptied.
  • $(modal).bind('loadStop'): (name to stay consistent with resizeStop and dragStop, could be loadEnd), content was added to the modal and Drupal.attachbehaviors() has been run.

A little extra is that all submit and buttons are added as jQuery dialog buttons :)

There is still work to be done, but the worst of it is done. Custom class, background opacity and show animation were not ported for now but that's pretty easy to do.

Small api change, the function
Drupal.CTools.Modal.modalContent = function(content, css, animation, speed)

is now

Drupal.CTools.Modal.modalContent = function(content, css, settings)

with

animation = settings.animation
speed = settings.animationSpeed

If you encounter issues with forms during your testing please try this patch before killing me : http://drupal.org/node/1324238#comment-5360410

There is still work left but i'd rather have feedback now just in case.

Comments

merlinofchaos’s picture

How does this work with the styled modal in the ajax sample?

nod_’s picture

Well, like i said it's not adding the custom class for styling. But it works and load animation is customized correctly.

It'll be very easy to add the class for styling I just got lazy toward the end.

(edit) and size values are correct too.

nod_’s picture

Status: Needs review » Needs work

umm you can actually go pretty far overriding $.ui.dialog.prototype._create to handle custom HTML dialog but not far enough.

If custom html has to be supported ideally that means introducing dialog templates (the same way jquery ui tabs works). In any case this'll end up a custom jquery plugin that uses ui.dialog if modalTheme == CToolsModalDialog and a custom renderer that takes care of making drag an resize available to the custom HTML dialog.

For custom templates, without resizing it's not that bad, but if we need to support this too it's going to be a nightmare. I guess if you're making a custom template you don't really care about resizing anyway.

Would that work for you to have a "normal" dialog resizable and dragable by default and if you're using a custom modalTheme dropping at least the resizable feature ?

merlinofchaos’s picture

Well, what matters is that I don't want to break the sites of people already relying on this feature.

I'd be more than happy to retain the existing modal.js functionality and allow the use of a more modern dialog to be switchable via a setting, though.

Dave Reid’s picture

Component: Code » Modal

Yeah that's probably a good approach. Make using the jQuery UI modal optional and opt-in so that people can slowly switch over. I fully support that.

nod_’s picture

Status: Needs work » Needs review
FileSize
8.86 KB
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View

Here it is, I've added code to ctools_ajax_sample.module to show off the new jquery dialog. I added a modal-jquery.js file to avoid touching modal.js once it's feature full and clean it might be good to merge some of the two files.

In the patch I override some of modal.js methods and call the new or old one depending on which type of modal is currently used.

Events are the same as in the first patche. To use it you have to call a ctools-modal-ctools-ui-dialog text-button.

Everything works fine in the demo, default, custom template, jquery modal :)

tim.plunkett’s picture

This never gets past the loading throbber for me. I might be using it wrong, but I don't really see anywhere in the new modal.show that would actually show the content.

tim.plunkett’s picture

Disregard #7, I was adding the JS too late.

The override() function scares me, but hopefully it won't be necessary in the long run.

nod_’s picture

Here you go, basically I added my processing wrapped in a if, on top of each relevant function and did a return; after dialog processing

I'm still not sure where to put the drupal_add_library('system', 'ui.dialog').

litwol’s picture

Assigned: Unassigned » litwol
Category: feature » task
Status: Needs review » Needs work
FileSize
23.95 KB

hijacking the issue :(

I've taken more minimal approach. ripped out everything i thought to be not useful for the time being, other pieces replaced with jquery.ui.dialog.

I've tested this on my own site (where i've used old/current modal.js extensively) and against panels-7.x-3.x in the layout builder/landing page wizard.

things to note:
1) I've removed all elements of custom modal theming based on Drupal.theme(). I've made assumption that this feature is rarely used due to (a) being poorly documented and (b) being rather complex (and thus reduce chances of it being used).
2) Do not despair. once port to jquery.ui.dialog is complete, custom theming will be reinstated. I haven't decided yet whether it will be totally custom drupalism or(/and?) offload it to http://jqueryui.com/themeroller/ . My personal preference is to offload heavy lifting to http://jqueryui.com/themeroller/. More on that as time allows..
3) I've rearranged some code around. Reading from top to bottom you'll find behaviors.attach(), reading from bottom to top you'll find responder command handlers.
4) Resulting modal.js is about 1/2 the original size, but based on my tests it is fully functional (i'm sure i missed some edge cases). I'm certain it'll grow back though :).

outstanding tasks:
1) Finish integrating all supported dialog options with ctools modal. Need to make sure to continue supporting all existing ctools-modal options and proxy them to jquery.dialog options as to avoid breaking dependent modules.
2) review and expand resizing_handler. currently it supports "scaling" operation with fraction based scaling, with min/max Width/Height constraints support. But i feel more testing is needed (see bugs).
3) Implement new responder command (dialog_settings?) that allows changing dialog settings on the fly.
4) Allow displaying dialog without title bar. I think this would require changing dialog-core "theme", but that relates to "things to note (2)" section above.

current obvious "bugs":
1) Displaying dialog at 100% width+height, it forces scroll bars to appear. pre-jquery.dialog implementation it was possible to make modal consume entire window dimensions without introducing scroll bars. I didnt have time to debug this yet, but ideally it should be possible to make dialog consume entire window space without introducing scroll bars.
2) display animation ("show") does not work for all supported animation methods. try to run with "slide" (click to open modal, then hit ESC to close, then click same modal again), you will see inconsistent sizing/placement behavior. This must be made consistent.

Further consideration:
I don't like current order of execution. current (based on old) workflow is first dialog/modal DOM is constructed, then made visible to end user as empty, then content is populated into the modal. Too much is wrong with this. for example jquery.ui.dialog will be able to handle auto-resizing better if it has content to resize around. Also see "bugs (2)" section above.
Consider different workflow: First construct hidden DOM containing all modal content in appropriate structure, then and only then initialize it to modal (effectively doing the reverse workflow of current).

P.s. sorry for dumping totally unrelated to original patch. I neglected to look through issue queue to see if some one started this already :(((.

swentel’s picture

Tried out the patch in #10. I've tested out quickly on adding / changing panes on panels. Works in my Display Suite environment as well for the 'dynamic field'.
So, so far no functional problems. The only (really tiny) bug I see is that when you hover on the little cross in the right corner, it moves a couple of pixels.
Tested on Google Chrome Mac. Will play with it a little more and provide more feedback later on normally.

uditmahajan’s picture

would love to have this feature.

Also as I posted on Modal dialog dynamic resizing, will it be possible to have transition for size change?

Currently if a modal is opened from link inside another modal, and if the size of the modals are different there is not animation of any sort. The modal just appears. I have seen websites where the size change is animated.

Moving to jquey it might be possible but still can you confirm this?

Also I will test the patch and let you know of any issue.

julien.reulos’s picture

Tested patch in #10 with:
- Display Suite module (configuring a field in a ctools modal frame)
- View Mode Modal module (it creates a link that opens a node in the ctools modal frame)
- custom module (to open a node add form with ctools_modal_text_button link)

In the 3 cases the patch works great. Didn't notice any problem at all except the bug mentionned in "2)": in case the link made with my custom module is set to "show" as display animation option, the modal will not show up after closing it with ESC key. It does work with "fadeIn" and "scale" animation options.

huytp’s picture

@uditmahajan:

Hi,

How about the progress? Can you do it? I have same problem in my form. When form modal submit have errors. The scroll will appear.

Thanks for share your knowledge.

minorOffense’s picture

Here's a re-roll of #9 to work with the latest dev build. I opted to use #9 instead since it creates a separate plugin (essentially) from the regular modals.

minorOffense’s picture

Here's an updated version of the last patch. This removes the hard-coded name of "ctools-ui-dialog" as the only way to trigger the jQuery UI Dialog.

Instead, there is a new parameter in the settings array called "library". Defaults to null (which triggers the default modal) but if you set it to "ui.dialog" in your modal settings, it will display the jQuery UI Dialog version.

Ex:

    'ctools-ui-dialog' => array(
      'library' => 'ui.dialog',
      //'modalTheme' => 'CToolsSampleModal',
      'throbber' => theme('image', array('path' => ctools_image_path('ajax-loader.gif', 'ctools_ajax_sample'), 'alt' => t('Loading...'), 'title' => t('Loading'))),
      // This is jQuery's dialog default values not required, just for reference
      'options' => array(
        'disabled' => TRUE,
        'autoOpen' => TRUE, // Not the default!
        //'buttons' => new stdClass(),
        'closeOnEscape' => TRUE,
        'closeText' => t('Close'),
        'dialogClass' => '',
        'draggable' => TRUE,
        'height' => 'auto',
        'hide' => NULL,
        'maxHeight' => FALSE,
        'maxWidth' => FALSE,
        'minHeight' => 300,
        'minWidth' => 600,
        'modal' => FALSE,
        'position' => FALSE,
        'resizable' => TRUE,
        'show' => 'fade',
        'stack' => TRUE,
        //'title' => '',
        'width' => 300,
        'zIndex' => 1000,
      ),
    ),

Beyond this, we'll have to get into mapping the default options to the jQuery UI Dialog settings to avoid having to have two separate "options" arrays. But it's a start.

minorOffense’s picture

And of course, I forgot to attach the patch in the last comment...

minorOffense’s picture

There's a bug with the last patch where you can only use one or the other on the same page. Meaning you can only use the CTools modal or the jQuery UI Dialog, but not both.

If anyone has any ideas on how to get both working on the same page I'm open to suggestions :-S

andypost’s picture

mgifford’s picture

It would be great if someone could backport this.

mgifford’s picture

Issue tags: +accessibility

tagging.

abratko’s picture

Thank you, your patch helped me.

jason.fisher’s picture

Status: Needs work » Needs review
FileSize
24.04 KB
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View

I have updated and cleaned up the patch from #10 a bit to work with the latest CTools 7.x-1.x-dev.

I have tested the patch with Panopoly and the standard Panels UI and it works fine, with some theming issues. This patch is missing parts that modules or themes may rely on.

jason.fisher’s picture

Status: Needs review » Needs work

redacted

jason.fisher’s picture

redacted

jason.fisher’s picture

Status: Needs work » Needs review
FileSize
18.28 KB
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View

Here is an updated patch from #17 for the latest 7.x-1.x-dev.

This patch uses settings to enable Dialog specifically.

The other patch from #23 switches everything that goes through CTools to Dialog. This still has the issue of using both types on the same page from #17, but I think that is an acceptable limitation for a feature that didn't exist before?

mpgeek’s picture

Patch at #27 worked for me.

Spleshka’s picture

Status: Needs review » Needs work

Patch may work (didn't test myself), but the hugest problem I see here is that applying that patch will break all previously existing modal dialogs that used ctools. So the implementation should follow the way of adding additional possibility to use jquery ui, but not replacing the modal completely.

discipolo’s picture

issue summary needs updating: the patch from #26 includes the changes to modal.js

not certain if its working: console.log(modalJQuery); on modal.js line 72 outputs "false", should there be a setting exposed to the config form to enable using jquery.ui.dialog?

a modal does open but i am not sure how to check if its a jquery dialog.

Paul B’s picture

Assigned: litwol » Unassigned
Category: Task » Feature request
Status: Needs work » Needs review

If the library is not added to the modal settings, my modal doesn't use jquery. I think the patch in #26 works fine, I'm not a ctools or jquery expert though so setting this to Needs review.

The last submitted patch, ctools-jquery-dialog-modal.patch, failed testing.

jhedstrom’s picture

FileSize
18.43 KB
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es). View

#26 needed rerolling after #1532174: Add class containing the "modal style" to modal landed. I also removed some debugging code, and cleaned up the comments.

serverofworld’s picture

Just applied changes for an example Jquery Dialog for people that want use a scale mode like it works now for Modal ctools.
The same approach, you have to add

'modalSize' => array(
    	'type' => 'scale',
    	'width' => 0.8,
    	'height' => 0.8,
)

For fixed mode the patch doesn't maintain, changes touched only "scale mode".

fox_01’s picture

patch #34 has relative paths to the drupal root but this has to be relative to the ctools module directoy so the patch does not apply

serverofworld’s picture

FileSize
18.83 KB

For #35 relative path

fox_01’s picture

#36 works for me

Paul B’s picture

rivimey’s picture

FileSize
21.6 KB
4.8 KB

Rerolling this patch for current 7.x-1.x because it fails to apply with git apply:

I have manually applied the change for the rejected hunks, above, and then fixed up some lines that had embedded tabs or bad indents (ctools_ajax_sample.module) and trailing whitespace (modal.js). The interdiff file describes these changes.

ctools$ git apply -v --rej ctools-jquery-dialog-modal-1397370-38.patch
ctools-jquery-dialog-modal-1397370-38.patch:37: space before tab in indent.
    	'modalSize' => array(
ctools-jquery-dialog-modal-1397370-38.patch:38: space before tab in indent.
    		'type' => 'scale',
ctools-jquery-dialog-modal-1397370-38.patch:39: space before tab in indent.
    		'width' => 0.8,
ctools-jquery-dialog-modal-1397370-38.patch:40: space before tab in indent.
    		'height' => 0.8,
ctools-jquery-dialog-modal-1397370-38.patch:41: space before tab in indent.
    	),
Checking patch ctools_ajax_sample/ctools_ajax_sample.module...
Checking patch js/modal.js...
error: while searching for:
    html += '    <div class="ctools-modal-content">' // panels-modal-content
    html += '      <div class="modal-header">';
    html += '        <a class="close" href="#">';
    html +=            Drupal.CTools.Modal.currentSettings.closeText + Drupal.CTools.Modal.currentSettings.closeImage;
    html += '        </a>';
    html += '        <span id="modal-title" class="modal-title">&nbsp;</span>';
    html += '      </div>';

error: patch failed: js/modal.js:125
error: while searching for:
    var html = '';
    html += '  <div id="modal-throbber">';
    html += '    <div class="modal-throbber-wrapper">';
    html +=        Drupal.CTools.Modal.currentSettings.throbber;
    html += '    </div>';
    html += '  </div>';


error: patch failed: js/modal.js:144
Hunk #13 succeeded at 298 (offset 3 lines).
Hunk #14 succeeded at 393 (offset 3 lines).
Hunk #15 succeeded at 402 (offset 3 lines).
Hunk #16 succeeded at 417 (offset 3 lines).
Hunk #17 succeeded at 440 (offset 3 lines).
Hunk #18 succeeded at 759 (offset 3 lines).
Hunk #19 succeeded at 808 (offset 3 lines).
Applied patch ctools_ajax_sample/ctools_ajax_sample.module cleanly.
Applying patch js/modal.js with 2 rejects...
Hunk #1 applied cleanly.
Hunk #2 applied cleanly.
Hunk #3 applied cleanly.
Hunk #4 applied cleanly.
Hunk #5 applied cleanly.
Rejected hunk #6.
Rejected hunk #7.
Hunk #8 applied cleanly.
Hunk #9 applied cleanly.
Hunk #10 applied cleanly.
Hunk #11 applied cleanly.
Hunk #12 applied cleanly.
Hunk #13 applied cleanly.
Hunk #14 applied cleanly.
Hunk #15 applied cleanly.
Hunk #16 applied cleanly.
Hunk #17 applied cleanly.
Hunk #18 applied cleanly.
Hunk #19 applied cleanly.
rivimey’s picture

Could someone familiar with this issue please clarify:

Is this patch fully backward-compatible with the existing ctools modal.js code?

It seems very unlikely to get committed unless it is fully compatible... :-)