$GLOBALS['TL_BODY'] does not work in Backend

[Fuzzyma]

Stuff you add to the array is not getting displayed at the end of the body. Actually $GLOBALS['TL_BODY'] is not even an array.

[Aybee]

I can not confirm this. $GLOBALS['TL_BODY'] expects to be an array. So you have to fill it like this

$GLOBALS['TL_BODY'][] = '<script src="files/js/myLateLoad.js"></script>';

[Fuzzyma]

Actually $GLOBALS['TL_BODY'] is not even an array.

I var_dumped it - its null.

$GLOBALS['TL_BODY'][] = '<script src="files/js/myLateLoad.js"></script>';

Thats how I did it. Script is not loaded neither is the code displayed in the html output.

[Aybee]

Where did you write your code? In dcaconfig.php or elsewhere?

[Fuzzyma]

In my widget which requires custom Javascript. I dont want to use TL_JAVASCRIPT because I want to load the script at the bottom of the page

[BugBuster1701]

then try this, like mootools:

$GLOBALS['TL_MOOTOOLS '][] = "<script type='text/javascript'>....  ";

[Fuzzyma]

Sorry to offend you but I wrote this issue to fix the bug (when it is a bug), that TL_BODY is not working. I am aware that I can use TL_MOOTOOLS but it remains a hack. I would like to use the correct type

[Aybee]

You don't offend me. Just wondering what you are doing wrong. It works, when I put it in

• system/dcaconfig.php
• a config.php of a module (extension)
• a template
• a file included with {{file::myfile.html5}}

That's why I asked where you put your code in. I don't know your "widget".

[Fuzzyma]

Its a normal backend widget. In its constructor (or in the generate method - i tried both) I wrote the code. Nothing happened.

class FormAdresspickerField extends FormTextField
{
    /**
     * Template
     *
     * @var string
     */
    protected $strTemplate = 'be_widget';

    public function __construct($arrAttributes = null)
    {
        if(TL_MODE == 'FE'){
            $strTemplate = 'form_widget';
        }

        parent::__construct($arrAttributes);

        $this->evals = $arrAttributes;

        $GLOBALS['TL_BODY'][] = '<script... ...>';

    }

// ...
}

Maybe the code helps

[Aybee]

Ah, ok. I just tested in FE. Don't know, if TL_BODY works in BE.

[fritzmg]

@Fuzzyma have you actually checked if TL_MOOTOOLS works? As far as I can see in the code, neither should work in the backend, because it's only handled in \Controller::replaceDynamicScriptTags which in turn is only called in \FrontendTemplate.

I think currently you can only inject JavaScript into a backend template by using the outputBackendTemplate hook.

[Fuzzyma]

No I didnt check it. I was quite sure, that this will work (since mootools is deeply anchored in contao) - looks like I was wrong. So this turns out to be more or less a feature request.

EDIT: just found this in BackendTemplate.php

        // MooTools scripts (added at the page bottom)
        if (!empty($GLOBALS['TL_MOOTOOLS']) && is_array($GLOBALS['TL_MOOTOOLS']))
        {
            $strMootools = '';

            foreach (array_unique($GLOBALS['TL_MOOTOOLS']) as $script)
            {
                $strMootools .= "\n" . trim($script) . "\n";
            }

            $this->mootools = $strMootools;
        }

same goes with TL_CSS and TL_JAVASCRIPT but TL_HEAD or TL_BODY is not listed.

[fritzmg]

Ah yes, I missed that. Yeah, TL_BODY should get processed in the BackendTemplate as well.

[leofeyer]

@contao/developers Do you think the back end should support TL_HEAD and TL_BODY?

[aschempp]

Sometimes that would have been handy in the past. But apparently I always found other solutions.

As it would be a feature, I wonder what would be the best way to add something like that in a Symfony way. I already did some thinking on a "add page output" service but I havent come up with a good way.

[fritzmg]

Since TL_MOOTOOLS is already processed in the backend template, I'd consider it a bug that TL_BODY isn't, not a feature.

[discordier]

It is a feature and more over, it alters the current behaviour. It will now add stuff in the backend that was so far guaranteed to only get added in the frontend. I wonder if we can call this incompatible change, as this is arguable but it definitely is a feature and not a bug.

[Fuzzyma]

This "stuff" would be only added when it's in the array. And it's only in the array if the user put in there. Since it wasn't supported till now I would be surprised if anyone would have added anything to the array when the backend mode is active. The only thing I can imagine is the preview of Frontend elements where a custom module is imported or something. But even then it most likely would only add behavior which is related to this module and not break anything

[fritzmg]

And it's only in the array if the user put in there.

Yes, but the user might have put it there for the Frontend only.

[Fuzzyma]

When he put it there for frontend only then there would be no problem anyway

[fritzmg]

When he put it there for frontend only then there would be no problem anyway

It could have unintended side effects in the backend.

[Fuzzyma]

Thats what I tried to point out. In most cases the added code just would not work - which is no "bad" side effect itself. In some cases it will work as it should. Only in some cases it will interfer with the backend code (e.g. jquery vs mootools) but that is a negligible amount imo.

[leofeyer]

It could have unintended side effects in the backend.

I'm also voting against changing the current behavior.

[leofeyer]

It is a feature and more over, it alters the current behaviour.

As discussed in Mumble on April 21st, this definitely implies a BC break.