Testing on Joomla staging and working perfectly fine for me.

Array (
    [text/javascript] => alert(1)
) 

What version are you using?

The latest version, 3.8.1.
It was working fine in the last/previous version.

Ahh sorry, right you are. I was using print_r() in the same module as opposed to the template.

We have observed this issue in PHP 7.2 in the latest Joomla

public function addScriptDeclaration($content, $type = 'text/javascript')
	{
		if (!isset($this->_script[strtolower($type)]))
		{
			$this->_script[strtolower($type)] = $content;
		}
		else
		{
			$this->_script[strtolower($type)] .= chr(13) . $content;
		}

		return $this;
	}

The issue is when this runs

if (!isset($this->_script[strtolower($type)]))

$this->_script is a string type, not an array.

Our workaround was to call as follows:

if (!is_array(JFactory::getDocument()->_script)) {
	JFactory::getDocument()->_script = array();
}

JFactory::getDocument()->addScriptDeclaration($script,'text/javascript');

By the way, the result of the issue is that JFactory::getDocument()->_script ends up containing only the first character of the $content variable.

You should never access a _VAR, this is per convention a private variable and as far as I know all are depreciated and will be removed in the next major version.

Of course, but this is the only current workaround for this bug that I’m
aware of.

On Fri, Aug 24, 2018 at 8:50 AM Robert Deutz notifications@github.com
wrote:

You should never access a _VAR, this is per convention a private variable
and as far as I know all are depreciated and will be removed in the next
major version.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#18491 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzCPyHPUBwSCC6GxTzVrHK6ht6cj0i7ks5uUBKagaJpZM4QREFX
.

--
Michael R. Fatica
Chief Executive Officer
MetaLocator.com
110 16th Street, Suite #1300
Denver, CO 80202
Toll Free: 1-800-231-6526
Local: 303-325-5912

What is the bug here?

Considering the variable declaration correctly initializes an array you're dealing with something changing the variable to a string. Unless it can be found that something in core is making this type change, it sounds like you're dealing with an extension doing harm.

When you call

JFactory::getDocument()->addScriptDeclaration($script);

The expected action is that the script be added to the document. This was not working in our tests. Looking closer we saw that it does not actually initialize the _script variable with the value provided. This only happens to us in a CLI context.

When we debugged the issue, we found that when we called
JFactory::getDocument()->addScriptDeclaration($script);

The addScriptDeclaration runs this code

if (!isset($this->_script[strtolower($type)]))
{
$this->_script[strtolower($type)] = $content;
}

However, $this->_script is of type "string" in our tests. AFAIK we are not interacting directly with _script at all (in our code anyway)

This assignment then doesn't make sense. Old PHP used to change the type of $this->_script to an associative array at this point
$this->_script[strtolower($type)] = $content;

Running PHP 7.2 the value of $this->_script[strtolower($type)] becomes the first character of the $content variable

@mbabker I think you're right.

$this->_script is a string type, not an array.

https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Document/Document.php#L142-L148

Can you reproduce this problem with a clean install so without any extension / template? It is working well here on 7.2.1 a clean install.

I can't. It's not a Joomla! bug, something else is polluting _script thanks for the quick attention and sorry for bother.

No reason to be sorry. At least we were able to help steer you in the right direction.

Hi

if i understand the issue correctly

please do a text search on the installation for files '*.php'
searching for regular expression
\['script'\][ \t]*=

the places that you will find this should be very few
and check if it is assigned a string

then in the files that you find that it is assigned a string check if it really used as head data or not
by searching for
->setHeadData(

if you find something you should report to the author of course

Also i thought to ask you to print real path of JDocument class by using PHP reflection
but by your description
i don't think that this is because a 'overridden' JDocument class

We found the issue in a custom template. It was a direct assignment of an
empty string. E.g.

->_script = ‘’;

Thanks!

On Fri, Aug 24, 2018 at 3:31 PM Georgios Papadakis notifications@github.com
wrote:

Hi

if i understand the issue correctly

please do a text search on the installation for files '.php'
searching for regular expression
['script'][ \t]=

the places that you will find this should be very few
and check if it is assigned a string

then in the files that you find that it is assigned a string check if it
really used as head or not
by searching for
->setHeadData(

if you find something you should report to the author of course

Also i thought to ask you to print real path of JDocument class by using
PHP reflection
but by your description
i don't think that this is because a 'overridden' JDocument class

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#18491 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzCP3sf4I9nQIDufQPjy9w37j8Dori_ks5uUHCwgaJpZM4QREFX
.

--
Michael R. Fatica
Chief Executive Officer
MetaLocator.com
110 16th Street, Suite #1300
Denver, CO 80202
Toll Free: 1-800-231-6526
Local: 303-325-5912

I have seen a few new methods (in Joomla core code)
that they throw exception if invalid data is passed
e.g. methods in JTable*

Also thinking that since

setHeadData() is only called a handful or less during runtime
and the data come from 3rd party code
and the issue is tricky because it appears only in php 7.2 where $v[] now behaves as string indexing and no longer converts variable $v to an array

why not put a check in setHeadData() of this (for J4) and throw an exception ?

public function setHeadData($data)
{
...
	$this->_style       = (isset($data['style']) && !empty($data['style'])) ? $data['style'] : $this->_style;
	$this->_scripts     = (isset($data['scripts']) && !empty($data['scripts'])) ? $data['scripts'] : $this->_scripts;
	$this->_script      = (isset($data['script']) && !empty($data['script'])) ? $data['script'] : $this->_script;
...

even in J3

(isset($data['script']) && !empty($data['script']))

maybe could become

$this->_script = (isset($data['script']) && !empty($data['script']) && is_array($data['script']))
  ?  $data['script'] : $this->_script;

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/18491

as far i understand not a core issue

as far i understand not a core issue

If we agree that this is an issue, it is a core issue. But not one that can be easily solved. Modules are rendered after the template is parsed. So in the template we can't use anything that modules add to the document. Some related discussion #24308.

The only core issue is the Document class member variables being public properties which allows them to be overwritten and their types changed. Nothing that can be done with the current API structure to fix that.