[#31203] The one way and the one container for store the script options

[Fedik]

Wiki: Adding the options to your JavaScript code

Example add the script option:

$options = array(
  'showAlert' => false,
  'consolelog' => true,
  'text' => 'Hi! I am "Text"!',
  'someArray' => array('one', 'two', 'and so on')
);
$doc->addScriptOptions('plg_examplejs', $options);

Access to the options in frontend:

Joomla.optionsStorage.plg_examplejs;

Links:

• old pull [#31203] The one way and the one container for store the script options #1319
• [#31203] The one way and the one container for store the script options - feature request

[yvesh]

Works without problems and offers a nice way to store javascript options 👍

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[anibalsanchez]

It is similar to #6006 but #6006 is more compact

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[Kubik-Rubik]

@Fedik Since we don't have a reaction for so long, is this still a valid feature request?

@DGT41 Could you please also review here? Thanks!

[Fedik]

@Kubik-Rubik yes, this is still a very very very very valid feature request 😉
at least I hope so 😄

[roland-d]

@Fedik I am not understanding the use of this PR. Can you explain it in more detail?

[roland-d]

Requires a blank line before the if statement according to codestyle.

[Fedik]

@roland-d for now if you need to add some JavaScript variable for one of your script you do:

$doc->addScriptDeclaration("
var foo = 'blabla';
var bar = ['more', 'blabla'];
");

Such approach have couple problem:

• you cannot easily modify it at runtime , only by parsing $doc->_scripts with some regex;
• this will add these variables in Global scope that can overlap the existing variable from another extension.

With my suggestion you can do:

$doc->addScriptOptions('myextension_name', array(
  'foo' =>  'blabla',
  'bar' => ['more', 'blabla']
));

and in javascript access to them:

console.log(Joomla.optionsStorage.myextension_name.foo);
console.log(Joomla.optionsStorage.myextension_name.bar);

As you can see all options under Joomla.optionsStorage.myextension_name instead of global scope.

Also you can modify your options at PHP runtime easily, eg. from plugin or where you need to do it.

$options = $doc->getScriptOptions('myextension_name');
$options['foo'] = 'ue ue';
$doc->addScriptOptions('myextension_name', $options);

// or more easy:
$doc->addScriptOptions('myextension_name', array('foo' => 'ue ue')); 
// it will be merged, and old 'foo' changed

Initially I made it for #1260, #6357, as with such approach we can move 99% of inline javascript to the files more easy, and rule them just by using the appropriate options in Joomla.optionsStorage

[joomla-cms-bot]

This PR has received new commits.

CC: @yvesh

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[dgrammatiko]

@Fedik I was speaking with some PLT members about the possibility to use more the data attributes to pass strings or PHP values. This way we drop the inline script just to pass some simple (or more complex data) from PHP to Javascript. Although a way to do it with inline script MUST also be available. So my idea is to drop JText::script() and replace it with this function you introduce here, and make sure that in most places (at least in the core) we just use data attributes. But that is more a 4.0 thing I guess...

[peterpeter]

@DGT41 And what means your comment to someone who wants testing patches? No further tests on this one?

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[roland-d]

@Fedik Can this be used next to what we have now? In that case we may be able to work on this for 3.6 as there seems general consensus this is the way forward.

[Fedik]

@roland-d yes, it still valid,
I just need to check the conflicts, someday 😃

[joomla-cms-bot]

This PR has received new commits.

CC: @yvesh

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[roland-d]

@Fedik I had another go at this PR and it's great. I now fully understand what it does and see great potential for it :) Thanks for the follow-up even though it has taken 2 years. Let's get it done for 3.6.

[roland-d]

I have tested this item ✅ successfully on 852311a

I have added the example array to the view.html.php file of com_content on the frontend. After that loaded the page and I was able to access the JavaScript options using the console editor.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[laoneo]

I have tested this item ✅ successfully on 852311a

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[roland-d]

We have 2 successful tests, setting to RTC.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[brianteeman]

Setting to needs review. As the pretty print requires a php version higher than the joomla minimun

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[Fedik]

@brianteeman JSON_PRETTY_PRINT in use when it available 😉

$pretyPrint  = (JDEBUG && defined('JSON_PRETTY_PRINT') ? JSON_PRETTY_PRINT : false);

[brianteeman]

Thanks for confirming that - all good - setting back to RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3072.}

[Kubik-Rubik]

Thank you @Fedik and all testers!