5.4 Block Edit Problem?
Permalink 1 user found helpful
As of version 5.4, when the new AJAX block update approach was implemented, any embedded JavaScript within a block's view doesn't seem to get executed, whereas it did in 5.3.x.
I have some embedded JS within my block's view.php which uses "document.write" to output a string. It works fine when the entire page is refreshed (such as when edit mode is first entered), but the JS is not executed after editing the block and clicking the "Update" button. This did work in 5.3 (probably because the entire page was refreshed in that version).
Can anyone else confirm this? And if it is confirmed, is this a bug that should be addressed, or must we no longer use embedded scripts in block views?
-Steve
I have some embedded JS within my block's view.php which uses "document.write" to output a string. It works fine when the entire page is refreshed (such as when edit mode is first entered), but the JS is not executed after editing the block and clicking the "Update" button. This did work in 5.3 (probably because the entire page was refreshed in that version).
Can anyone else confirm this? And if it is confirmed, is this a bug that should be addressed, or must we no longer use embedded scripts in block views?
-Steve
Thanks for the reply, Mike. I understand how AJAX works and the benefits of using it. However, jQuery is perfectly capable of executing JS after an AJAX request, so the question remains... Is the current behavior the intended behavior, or will it be "fixed" so that JS is in fact executed after a block save? After all, the current behavior breaks stuff that used to work in 5.3.
-Steve
-Steve
We'll try and take a look at this. We had some problems early on because of the way the javascript was executing, sometimes editing and re-editing something multiple times would cause JS to break with strangely coded addons. But that was pretty early in the development cycle and we've fixed a number of the ways the ajax process works, so it's possible that adding javascript to these auto header items would have no ill effect and would fix the problems you're mentioning.
I just posted an update that should address this. I'd appreciate some assistance with cross-browser testing etc... This fixes things like flash video not working since swfobject doesn't load, etc... however it isn't perfect in Firefox (not sure why.)
Hi Andrew,
My block is pretty simple; all it does is output a string using document.write from view.php. Unfortunately, there appears to be no change in behavior with RC2. I tried Safari, Opera, and Firefox on the Mac, and no go.
-Steve
My block is pretty simple; all it does is output a string using document.write from view.php. Unfortunately, there appears to be no change in behavior with RC2. I tried Safari, Opera, and Firefox on the Mac, and no go.
-Steve
Ok, I'm an idiot. Of course document.write isn't going to execute after an ajax request; it executes only when the page is being rendered! I simply had to implement things a bit differently if the page is in edit mode. So basically, JS inside an embedded script _is_ being executed after a block edit in 5.4.0 release. Thanks!
-Steve
-Steve
Hi Steve,
this is a very important point. I really don't understand why it is not so underlined by other developers. It drives me crazy. Could you provide an example?
Thanks man!
this is a very important point. I really don't understand why it is not so underlined by other developers. It drives me crazy. Could you provide an example?
Thanks man!
Hi digitmaster,
What I had encountered was a JavaScript issue and not anything specific to C5. Basically, the JS method "document.write()" executes "inline" when the page is being parsed and rendered, and a block I had written depended on that behavior. Everything worked fine when I initially wrote the block, because after dismissing the block editing dialog, the entire page would refresh (and the function would therefore execute), so no problem. Then, version 5.4 of Concrete5 was released, and block update behavior changed. Instead of refreshing the entire page, C5 now uses AJAX to update the block after editing. Thus, my block stopped updating after it was edited, so I initially suspected an issue with C5 until I realized what was happening (or not happening as the case may be).
Anyway, the solution is to simply use jQuery to perform any updates to the page after editing the block. Often, your block can be updated in the same manner whether the page is being edited or not, but if you need to handle the two situations differently for any reason, just check to see if you're in edit mode in your block's view.php like so...
Hope that helps,
-Steve
What I had encountered was a JavaScript issue and not anything specific to C5. Basically, the JS method "document.write()" executes "inline" when the page is being parsed and rendered, and a block I had written depended on that behavior. Everything worked fine when I initially wrote the block, because after dismissing the block editing dialog, the entire page would refresh (and the function would therefore execute), so no problem. Then, version 5.4 of Concrete5 was released, and block update behavior changed. Instead of refreshing the entire page, C5 now uses AJAX to update the block after editing. Thus, my block stopped updating after it was edited, so I initially suspected an issue with C5 until I realized what was happening (or not happening as the case may be).
Anyway, the solution is to simply use jQuery to perform any updates to the page after editing the block. Often, your block can be updated in the same manner whether the page is being edited or not, but if you need to handle the two situations differently for any reason, just check to see if you're in edit mode in your block's view.php like so...
// $c is a reference to the current collection (page) if ($c->isEditMode()) { $('#myMessageDiv').html('My Message'); } else { // Do something different if page is not being edited. }
Hope that helps,
-Steve
Thank you Steve. I think this is exactly the point. unfortunately I cannot understand on the fly the jQuery code like I do with php. What does the line exactly do?
Thanks again.
$('#myMessageDiv').html('My Message');
Thanks again.
That's just run-of-the-mill jQuery. It's finding a DIV with the id "myMessageDiv" and replacing its contents with the string "My Message."
jQuery is just a popular JavaScript framework. There are others, of course, but jQuery is hugely popular because of the way it allows you to manipulate the DOM in powerful ways with minimal code. You can learn everything you want to know (and more) about jQuery here...
http://jquery.com/
If you want to become proficient with jQuery (or any client-side scripting), you just have to invest the time learning it. There's no way around that.
EDIT: Just to be clear... Nothing says you _must_ use jQuery. You can use plain old JS without making use of any framework at all. The equivalent of the above code in plain vanilla JS would be...
-Steve
jQuery is just a popular JavaScript framework. There are others, of course, but jQuery is hugely popular because of the way it allows you to manipulate the DOM in powerful ways with minimal code. You can learn everything you want to know (and more) about jQuery here...
http://jquery.com/
If you want to become proficient with jQuery (or any client-side scripting), you just have to invest the time learning it. There's no way around that.
EDIT: Just to be clear... Nothing says you _must_ use jQuery. You can use plain old JS without making use of any framework at all. The equivalent of the above code in plain vanilla JS would be...
document.getElementById('myMessageDiv').innerHTML = 'My Message';
-Steve
Thanks Steve. Now the code is clear.
I know about jQuery and I also did some easy code with it. I just not have it under my fingers like the rest of languages I use.
You gave me a good tip. Leave just the time to apply it to my code and I will give you feedback. By now, have some karma points from me.
-Frank
I know about jQuery and I also did some easy code with it. I just not have it under my fingers like the rest of languages I use.
You gave me a good tip. Leave just the time to apply it to my code and I will give you feedback. By now, have some karma points from me.
-Frank
...but:
my problem is that I must reload the page one time after that the block is edited.
once again: no way out and I will use the 5.3.3.1
I would send money to whom may solve this issue.
my problem is that I must reload the page one time after that the block is edited.
once again: no way out and I will use the 5.3.3.1
I would send money to whom may solve this issue.
> my problem is that I must reload the page one
> time after that the block is edited
Hi Frank,
Can you be more specific about what it is you're trying to accomplish? Why do you think you need to load the page after editing the block? There's likely a way to do it without reloading the page. I mean, you can do pretty much anything you want, as you have access to both server- and client-side logic.
I'd be glad to try to help, but I would need more detail. Can you provide some code or describe the issue more thoroughly?
-Steve
> time after that the block is edited
Hi Frank,
Can you be more specific about what it is you're trying to accomplish? Why do you think you need to load the page after editing the block? There's likely a way to do it without reloading the page. I mean, you can do pretty much anything you want, as you have access to both server- and client-side logic.
I'd be glad to try to help, but I would need more detail. Can you provide some code or describe the issue more thoroughly?
-Steve
Hi Steve,
thanks. Let me describe the scenario.
1. I have an editable area div called 'central_content'.
2. As I add a block, for example, text and pictures to 'central_content', its height increases, sure.
3. A sidebar div called 'leftcol' should have the height same as 'central_content' immediately after an update of 'central_content'.
In 5.4.x as I perform an update in the central_content, the leftcol does not syncronize its height with the central_content. I must reload the page.
That's it.
I would someting like this (don't look at the syntax but at the meaning):
thanks. Let me describe the scenario.
1. I have an editable area div called 'central_content'.
2. As I add a block, for example, text and pictures to 'central_content', its height increases, sure.
3. A sidebar div called 'leftcol' should have the height same as 'central_content' immediately after an update of 'central_content'.
In 5.4.x as I perform an update in the central_content, the leftcol does not syncronize its height with the central_content. I must reload the page.
That's it.
I would someting like this (don't look at the syntax but at the meaning):
$("#leftcol").height($('#central_content').height());
How are you setting the heights equal when the page loads?
-Steve
-Steve
html onload event
<body onload="setHeight();">
and it works perfectly on 5.3.3.1
On 5.4 works as well but not after pushing the update button in the block.
I have to reload the page manually in the browser. Of course, this is just a little issue in edit mode, because the page works fine online for a visitor. *The problem* is that during edit, after a simple block update, the content is growing and what you I'm seeing is not what I'm getting.
May I use an event like onBlockUpdate? Does it exist?
<body onload="setHeight();">
and it works perfectly on 5.3.3.1
On 5.4 works as well but not after pushing the update button in the block.
I have to reload the page manually in the browser. Of course, this is just a little issue in edit mode, because the page works fine online for a visitor. *The problem* is that during edit, after a simple block update, the content is growing and what you I'm seeing is not what I'm getting.
May I use an event like onBlockUpdate? Does it exist?
Finally I did it!
I've solved the problem at the root. Just ovverride the appropriate settings for edit, add, and delete block. Bye bye Ajax benefits for those three(why not, if I need it to be so?) and a fresh beer for me.
Yeeah!!
reason edit: fresh beer
I've solved the problem at the root. Just ovverride the appropriate settings for edit, add, and delete block. Bye bye Ajax benefits for those three(why not, if I need it to be so?) and a fresh beer for me.
Yeeah!!
reason edit: fresh beer
Congrats!
If the sidebar is fixed width, I was going to suggest an alternative approach to your mark-up and CSS which would eliminate the need for any JS at all.
Glad you solved it though,
-Steve
If the sidebar is fixed width, I was going to suggest an alternative approach to your mark-up and CSS which would eliminate the need for any JS at all.
Glad you solved it though,
-Steve
Thanks Steve!
all the elements have fixed width. The problem was just the height.
So now I can migrate my contents that are using that template from 5.3.3.1 to 5.4.x. I'll have same behaviour but new environment, dashboard, fixes...etc.
Cheers.
all the elements have fixed width. The problem was just the height.
So now I can migrate my contents that are using that template from 5.3.3.1 to 5.4.x. I'll have same behaviour but new environment, dashboard, fixes...etc.
Cheers.
Can you show an example as to how you overrode the add, edit and delete code to do the full refresh? I'm having the same issue myself in my embedded javascript in my view file and I'd like to get details on exactly how this fix works. Thanks!
hi digitmaster,
can you please share that fixes.. may be that changes help the programmers like me.
Thanks,
Raj
can you please share that fixes.. may be that changes help the programmers like me.
Thanks,
Raj
Mike