Forums

Custom Block Auto.js File Only Triggered Once

Permalink
Hi there. I'm not sure if this is an issue others have noticed or if its just me.

I have a custom block that uses a auto.js file to change the admin form options displayed in add.php and edit.php (form.php actually). They are triggered by the change of a dropdown menu... select menu item 'a' and a text field for it appears, select menu item 'b' and a page link box appears, etc...

What I have noticed this morning is that it will run only once. If I click on the box to edit the auto.js seems to do what its supposed to (display the correct set of inputs). But if I cancel or save then click to edit the box again it fails to select the appropriate set of inputs.

To get around this I put the code directly in the form.php file and it works without fail.

Any ideas? Is this a bug in 5.7? or just in my little world?
 
andrew replied on at Permalink Reply
andrew
It's not a bug, per se – but it has bitten us in the past. In general, we register all the javascript events that we need in a concrete event, and that is defined in auto.js, and then we fire that event in form.php. For example, in the survey block's auto.js:

(function($){
    'use strict';
    var container, options, template, input;
    Concrete.event.bind('survey-edit-open', function() {
        container = $('div.survey-block-edit');
        options = $("div.poll-options", container);
        template = _($("script[role='option']", container).remove().html()).template();
        input = $('input.option-value', container);
        container.find('button.add-option').click(function(e) {
            addOption();
            e.preventDefault();
            return false;
        });
        attachDelete(options);
    });
Viewing 15 lines of 16 lines. View entire code block.


(I've snipped the rest of the code)

And then in edit.php, we fire that event.

<script type="text/javascript">
    Concrete.event.fire('survey-edit-open');
</script>


You can also use ConcreteEvent.fire, ConcreteEvent.trigger, ConcreteEvent.pub, etc...
Chrouglas replied on at Permalink Reply
Ha! That's the long answer for 'You're doing it wrong'.
Thanks for the info Andrew. I will give your version a try next time :)
Cheers,
Chris
andrew replied on at Permalink Reply
andrew
No problem! This has also bitten us too – so I wanted to clarify ;)
snobo replied on at Permalink Reply
snobo
Andrew,

I'm looking for a solution of a somewhat related problem. I need to execute some bit of JS to process the Content block output. Normally I do it just in my general JS file included in the theme (although I could have included it in view.js just as well). But then it's not run after the block's content is updated.

I see from this post that including it in auto.js won't help either. I understand the idea of registering a custom event, but when would I trigger it? In my case edit.php is not a right place for it. And firing it in view.php means plaguing the public page HTML with inline <script> tags which doesn't seem right to me.

I wonder, is there any JS event in C5 fired after updating block that I could hooked on? Generally, is there any docs on 5.7 JS hookable events? Or is there any other right way to do it?
shoutmediaca replied on at Permalink Reply
shoutmediaca
snobo,

I just ran into the exact same problem.

I was able to solve it using this in auto.js:

Concrete.event.bind('EditModeUpdateBlockComplete', function () {
// Block Updated
});
snobo replied on at Permalink Reply
snobo
Amazing! Thanks a million! I hoped that an event like this exist. Will try that.

Still, I wonder, why there is no documentation on this? Generally, after years of trying to work with C5 I have to cocnulde that its documentation is (still) terrible. Well in some parts it's ok or even good, but then in others it's missing, or incomplete, or outdated, or misleading. And you spend hours, days or weeks trying to fo find an answer in forums, reverse engineering the source code or just guessing...
shoutmediaca replied on at Permalink Reply
shoutmediaca
I agree that the documentation still has a long way to go, but it's a lot better than it was, especially since 5.7.5. If I come across an undocumented issue that takes me a long time to solve, I try to come back and post my solution in threads like this one in hopes that it will save somebody some time. I trust that other developers would do the same.
snobo replied on at Permalink Reply
snobo
The problem with the forum that search engine is also far from perfect. It seem to search only by keywords specified, and not by message context. So searching the forum, in my experience, is also a problem... Thankfully Google comes to help, but then it's less focused...