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

Shotster
 
Mnkras replied on at Permalink Reply
Mnkras
after the page is published, depending on the edits, it will either do a full refresh or an ajax refresh i believe, the ajax refresh is not an actual face refresh so the javascript thinks that it has been already executed, its how they sped up the saving in 5.4.

Mike
Shotster replied on at Permalink Reply
Shotster
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
andrew replied on at Permalink Reply
andrew
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.
andrew replied on at Permalink Reply
andrew
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.)
Shotster replied on at Permalink Reply
Shotster
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
Shotster replied on at Permalink Reply
Shotster
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
digitmaster replied on at Permalink Reply
digitmaster
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!
Shotster replied on at Permalink Reply
Shotster
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...

// $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
digitmaster replied on at Permalink Reply
digitmaster
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
$('#myMessageDiv').html('My Message');
exactly do?

Thanks again.
Shotster replied on at Permalink Reply
Shotster
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...

document.getElementById('myMessageDiv').innerHTML = 'My Message';

-Steve
digitmaster replied on at Permalink Reply
digitmaster
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
digitmaster replied on at Permalink Reply
digitmaster
...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.
Shotster replied on at Permalink Reply
Shotster
> 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
digitmaster replied on at Permalink Reply
digitmaster
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):
$("#leftcol").height($('#central_content').height());
Shotster replied on at Permalink Reply
Shotster
How are you setting the heights equal when the page loads?

-Steve
digitmaster replied on at Permalink Reply
digitmaster
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?
digitmaster replied on at Permalink Reply
digitmaster
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
Shotster replied on at Permalink Reply
Shotster
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
digitmaster replied on at Permalink Reply
digitmaster
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.
Doki replied on at Permalink Reply
Doki
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!
rajeshpuliyoor replied on at Permalink Reply
rajeshpuliyoor
hi digitmaster,
can you please share that fixes.. may be that changes help the programmers like me.

Thanks,
Raj