Code in auto.js that breaks Cancel and Save buttons in Add/Edit block window
Permalink
Hi,
My block needs to be able to open additional dialog boxes when adding a new block or editing an existing one. I have made good progress on the main form.php file for add.php and edit.php, but now I have started doing some tests to open new dialog boxes from within my form.php, and I have a problem with the following piece of code in auto.js (I have more javascript located in a <script> tag at the bottom of form.php) :
The problem is that creating a dialog box from the <div id="dialog_test" ...> element breaks concrete5's Cancel and Save buttons at the bottom of the form for add.php and edit.php. The Cancel button does not close the window anymore. The Save button does save the data in the database, but does not close the window too. I can still click on the top-right cross to close it, though. Furthermore, I noticed that when this issue happens, the vertical scroll bar of Firefox for the entire website page in Edit mode disappears. I have really no idea why.
Another important thing that I noticed is that this problem does not even occur all the time ! Sometimes, I can edit the block and click save or cancel, and the add/edit window closes just fine. I don't know how to reproduce it consistently.
The div for the dialog box in form.php is :
The javascript code above does what it is supposed to do. I also tried to comment some specific parts of it, but the issue really comes from the simple fact of doing
Caching is disabled, and I reverted to the default theme.
Please tell me, what could the problem be ? I really cannot put everything on form.php and need to open additional boxes.
Other forum threads with similar issues, but I didn't find a solution in them :
http://www.concrete5.org/community/forums/usage/content-block-save-...
http://www.concrete5.org/community/forums/customizing_c5/saveedit-b...
My block needs to be able to open additional dialog boxes when adding a new block or editing an existing one. I have made good progress on the main form.php file for add.php and edit.php, but now I have started doing some tests to open new dialog boxes from within my form.php, and I have a problem with the following piece of code in auto.js (I have more javascript located in a <script> tag at the bottom of form.php) :
$(function() { $("#dialog_test").dialog({ autoOpen: false, modal: true, open: function() { $('#button-id-display').text($("#dialog_test").data('button-id')); } }); $('[id^=cs_button]').click(function() { // here, "this" is the DOM element on which the event was hooked var buttonId = this.id; $('#dialog_test') .data('button-id', buttonId) .dialog('open'); });
Viewing 15 lines of 16 lines. View entire code block.
The problem is that creating a dialog box from the <div id="dialog_test" ...> element breaks concrete5's Cancel and Save buttons at the bottom of the form for add.php and edit.php. The Cancel button does not close the window anymore. The Save button does save the data in the database, but does not close the window too. I can still click on the top-right cross to close it, though. Furthermore, I noticed that when this issue happens, the vertical scroll bar of Firefox for the entire website page in Edit mode disappears. I have really no idea why.
Another important thing that I noticed is that this problem does not even occur all the time ! Sometimes, I can edit the block and click save or cancel, and the add/edit window closes just fine. I don't know how to reproduce it consistently.
The div for the dialog box in form.php is :
<div id="dialog_test" class="ui-helper-hidden" title="Dialog test"> <p>The id of the button you clicked on is : <span id="button-id-display"></span></p> </div>
The javascript code above does what it is supposed to do. I also tried to comment some specific parts of it, but the issue really comes from the simple fact of doing
$("#dialog_test").dialog({ });
Caching is disabled, and I reverted to the default theme.
Please tell me, what could the problem be ? I really cannot put everything on form.php and need to open additional boxes.
Other forum threads with similar issues, but I didn't find a solution in them :
http://www.concrete5.org/community/forums/usage/content-block-save-...
http://www.concrete5.org/community/forums/customizing_c5/saveedit-b...
Using a <div> as the body of a popup dialog is a destructive process. The original div is moved to the end of the html body and the dialog markup built about it there. When closed, all the elements are removed.
I find it is more reliable to leave the original markup alone but hidden and clone it in jQuery before using the cloned element to create the new popup dialog. The main thing you need to take care of is to ensure that any #id attributes are either removed or modified so you don't end up with replica #ids.
I find it is more reliable to leave the original markup alone but hidden and clone it in jQuery before using the cloned element to create the new popup dialog. The main thing you need to take care of is to ensure that any #id attributes are either removed or modified so you don't end up with replica #ids.
Many thanks for your answers !
Unfortunately, no, there are no errors or warnings in the console/Firebug/Webdeveloper add-on.
However, in the meantime and after searching with different words I found this :http://www.concrete5.org/community/forums/customizing_c5/save-butto... With another answer from you JohntheFish !
Unfortunately, we don't know if solidcoresoftware was able to solve the problem. And I cannot use tabs for this.
JohntheFish, wouldn't you have an idea to work around the issue ? :) You have been very helpful
As for your answer to me, I am not sure I have understood why it is bad to use <div>s as the body of dialogs, but I'll keep your advice in mind. It's the first time I create dialogs.
Thank you again
Unfortunately, no, there are no errors or warnings in the console/Firebug/Webdeveloper add-on.
However, in the meantime and after searching with different words I found this :http://www.concrete5.org/community/forums/customizing_c5/save-butto... With another answer from you JohntheFish !
Unfortunately, we don't know if solidcoresoftware was able to solve the problem. And I cannot use tabs for this.
JohntheFish, wouldn't you have an idea to work around the issue ? :) You have been very helpful
As for your answer to me, I am not sure I have understood why it is bad to use <div>s as the body of dialogs, but I'll keep your advice in mind. It's the first time I create dialogs.
Thank you again
Hi again,
Instead of calling the dialog() function directly on the <div>, I tried using it by doing $.fn.dialog.open(...), and the problem does not seem to happen anymore. Initially, I had read the following posts :http://www.concrete5.org/community/forums/customizing_c5/using-regu... , and http://www.concrete5.org/community/forums/customizing_c5/jquery-ui-...
In which Andrew explains that concrete5 started developing dialogs before jQuery did. However, jQuery UI's dialog eventually became better, and people wanted to use it. ccm.dialog.js then became a wrapper for jQuery UI dialog. I see that the code for the overwritten dialog function is now in concrete/js/ccm_app/legacy_dialog.js (and a minified version is included into concrete/js/ccm.app.js)
From those posts, and the code, it seems that we should be able to use the dialog method as I first wanted to (which is the way everyone use it outside concrete5, is it not ?). Therefore, I think the problem I encountered might come from a bug elsewhere in concrete5's code. I would really like to hear what you (JohntheFish or anybody else) think about that.
We can see in the code below that jQuery UI Dialog is used if we call the dialog method on a <div> :
I'll see if I can do everything I want by calling $.fn.dialog.open(object literal), but this seems more limited. And I already noticed that onOpen does not behave the same way as open: function() { ... }
Instead of calling the dialog() function directly on the <div>, I tried using it by doing $.fn.dialog.open(...), and the problem does not seem to happen anymore. Initially, I had read the following posts :http://www.concrete5.org/community/forums/customizing_c5/using-regu... , and http://www.concrete5.org/community/forums/customizing_c5/jquery-ui-...
In which Andrew explains that concrete5 started developing dialogs before jQuery did. However, jQuery UI's dialog eventually became better, and people wanted to use it. ccm.dialog.js then became a wrapper for jQuery UI dialog. I see that the code for the overwritten dialog function is now in concrete/js/ccm_app/legacy_dialog.js (and a minified version is included into concrete/js/ccm.app.js)
From those posts, and the code, it seems that we should be able to use the dialog method as I first wanted to (which is the way everyone use it outside concrete5, is it not ?). Therefore, I think the problem I encountered might come from a bug elsewhere in concrete5's code. I would really like to hear what you (JohntheFish or anybody else) think about that.
We can see in the code below that jQuery UI Dialog is used if we call the dialog method on a <div> :
$.widget.bridge( "jqdialog", $.ui.dialog ); // wrap our old dialog function in the new dialog() function. jQuery.fn.dialog = function() { // Pass this over to jQuery UI Dialog in a few circumstances if (arguments.length > 0) { $(this).jqdialog(arguments[0], arguments[1], arguments[2]); return; } else if ($(this).is('div')) { $(this).jqdialog(); return; } // LEGACY SUPPORT return $(this).each(function() {
I'll see if I can do everything I want by calling $.fn.dialog.open(object literal), but this seems more limited. And I already noticed that onOpen does not behave the same way as open: function() { ... }
sounds a bit like it stops loading .js and .css files after an error