$.fn.dialog.function.open is not a function

Permalink Browser Info Environment
I installed this addon (1.2), on to a site running 5.5.2.1 and dropped the block into the page. I find that although the ui code is in the page source, attempting to open a dialog fails (error message shown in Firebug) with "$.fn.dialog.function.open is not a function" and the dialog does not open. I went back to the defauklt theme with nothing but the code to open the ui, still the same problem so not an issue with the theme.

I eventually found that I need this:

<script type="text/javascript" src="/concrete/js/ccm.app.js"></script>


just before the closing </body> tag. Inserting it into the header does not work. Now that it's working the CSS is also messed up so I guess it needs something else too, but I haven't figured that out yet.

Type: Discussion
Status: New
jero
View Replies: View Best Answer
JohntheFish replied on at Permalink Reply
JohntheFish
That is because C5 has its own legacy dialog widget(as in the C5 developer documentation and older howtos). Before 5.5.1, you couldn't use the jQuery.ui dialog, you had to use the C5 version. With 5.5.1 the C5 legacy dialog was revised to skin the actual jQuery.ui dialog and allow both to coexist.

So from 5.5.1 onwards, if you use a dialog, you also need ccm.app.js and ccm.app.css.

The location is ideally immediately after jquery.ui because it immediately places a wrapper about the dialog.

I hadn't really thought of this change to C5 in association with the Load.ui addon before, so thanks for drawing it to my attention.

I am loath to change the existing block or attribute because that would not be backward compatible.

One solution that comes to mind would be another block and attribute (in the same addon), for 5.5.1 onwards, that fills the gap you have described.

I will have to think on this further.
JohntheFish replied on at Permalink Reply
JohntheFish
PS. If you are developing with a dialog, you are probably doing stuff that is more complex than the simple Load.UI block was conceived to support.
JohntheFish replied on at Permalink Reply
JohntheFish
A new version with ccm.app attribute and block has been uploaded.
jero replied on at Permalink Reply
jero
Thanks. I got a fatal error on update:

Fatal error: Call to undefined method Block::getbyhandle() in /var/www/packages/jl_load_ui/controller.php on line 50

I changed from

$b = Block::getByHandle('jl_load_ui_and_ccm_app');


to

$b = BlockType::getByHandle('jl_load_ui_and_ccm_app');


and after rolling back the package version in the database the install went through OK.

However, although ccm.app.js and ccm.app.css are most definitely present in the <head> section now, I'm still getting the error. Putting ccm.app.js immediately before the closing </body> tag makes it all work.

FYI I am endeavouring to launch a dialogue in response to a click on an element. The dialogue contents are loaded thru a tools url via AJAX and comprises a simple form - in essence an "are you sure?" prompt. It's all working when logged in as admin, but not when logged in as joe-schmo user, unless I push the ccm.app.js into the footer of the page manually.
JohntheFish replied on at Permalink Best Answer Reply
JohntheFish
Thanks for fixing my upgrade bug. I will release v1.3.1 shortly with your fix in it (the upgrade just ran OK on my development system. I stupidly missed it earlier because I ran the tests of the new block and attribute on a fresh install).

The tests I ran for v1.3 was an html block in association with
1. new attribute.
2. the ...and_ccm_app block.
<div id="test-dialog">
<p>TEST</p>
</div>
<script>
$().ready(function() {
  $('#test-dialog').dialog();
});
</script>


This popped up the dialog in Greek Yogurt and in Flexpro One (by Tallacman Steve).

I also made sure it ran and popped the dialog in a fresh non-logged in session.

Considering the complexity of what you are doing, I guess that Load.UI was just an intermediate stage in your development while getting to the point of working out what needed to go in the Header/Footer for a long term solution.

Just had an idle thought. It is the main page calling up the dialog you have Load UI in and not the ajax response? (The ajax response will not render a header, so it would definitely have to all be in the footer there).

John

PS. A side effect of C5 dialogs is that they are destructive of the original DOM they pop. A trick I use for some of my addons is to clone the DOM and re-create it after closing the dialog. You may find that useful at some time.
jero replied on at Permalink Reply
jero
No problem. I did in fact go back to the greek yogurt theme to try and rule out any issues - last night it seemed to be having no effect, but this morning, post upgrade reverting to the standard theme is working as it should. Sometimes you're so close to the coalface you don't see the big picture I guess :(

I did notice that my hidden div gets eaten - nasty. That's one of the reasons I loaded using Ajax, but at least I know I'm not going nuts now!

Thanks for the feedback - much appreciated.

concrete5 Environment Information

Browser User-Agent String

Hide Post Content

This will replace the post content with the message: "Content has been removed by an Administrator"

Hide Content

Request Refund

You have not specified a license for this support ticket. You must have a valid license assigned to a support ticket to request a refund.