@jelo @LouisGac @tpartner : Good idea?

@DenisChenu What do you think, would you help to add this?

Easy way : just add a Plugin and register script in beforeQuestionRender . Quick system : let me 1/4 hour
In general : CClientScript::POS_END ? http://www.yiiframework.com/doc/api/1.1/CClientScript#registerScript-detail

Better system : a dropdown with 'register in HEAD/BODY/PAGELOAD etc ....' http://www.yiiframework.com/doc/api/1.1/CClientScript#registerScript-detail
1 hour

BUT : managing XSS .....
Must review the "save" attribute system totally : if user is on XSS : don't show the script (or show it without allowing to update).

Actually the readonly system seems broken : no real PHP system for readonly ....

Then , for XSS : up to 2 hours

I quick start one in develop (1/4 hour)

It should be a core feature, not a plugin.

I'd also rather stick to the question/group specific positions as they are now , otherwise you will have JS all over the place and the survey admin will forget where he put the JS in the first place.

XSS, see my IRC comment.

Yes, I think this would be a great feature for non-technical users who simply want to paste a snippet from the workarounds or forums.

I also think it should be a core feature but not visible if XSS is enabled.

core plugin done in 5 minutes

To move to a core feature : do like css_class

A plugin can be deactivated

Fix committed to develop branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=21453

LouisGac talk a lot .... take me more time ;)

Denis, you did not implement it the way suggested. Can you please read what I write before you start implementing it?

If we are in disagreement please lets us find us an agreement first before you start implementing it - otherwise it will end up in disappointment for either side.

What is the difference betwenn a Core Plugin and a Core system ?

What is the Cons/Pros of each

For plugin :
Pros :

1. can be deactivated
2. less code to review to have a pull request by external dev
3. some user can take the plugin and make their own

Else : i can quickly remove the plugin from core (and put in extension for 2.5X), no problem :)

I am not referring to pro or con plugin. I am referring to:

• A new placeholder in the question template needs to be added: {QUESTION_JS} or similar.
• I don't want people to put JS in headers or anywhere else in the page. It is confusing and you will have lost JS in some question which you cannot locate easily. The JS needs to appear where the {QUESTION_JS} tag is, not anywhere else.
• The JS field should use a proper Javascript highligther/editor.

Ah OK :).

Not for me then.

I strongly support this, but I cannot see how to vote for this in this new interface of Mantis.

I also mentioned this in the A-UI designs I made at:
https://app.moqups.com/tammoterhark@gmail.com/VMOrJNLtR0/view

Or more specifically at:
https://app.moqups.com/tammoterhark@gmail.com/VMOrJNLtR0/view/page/a6878cb62

Currently , with https://www.limesurvey.org/index.php?option=com_sobipro&pid=104&sid=115:addscripttoquestion&Itemid=729 and 3.0/develop.

Capture du 2017-02-02 14-08-04.png (39,237 bytes)   

Capture du 2017-02-02 14-08-04.png (39,237 bytes)   

I guess that this only works when Javascript is the same for all languages in this configuration. I guess that is the case in 99% of all situations. It was also like that in the example I provided.

Would love to see this, because it is much cleaner this way.

I see no real good reason to have different value for each language. Yes, there can have some situation where need a language string in JS, but i think it can be done with some $("#question{QID} .question-help").text() system.

For an exemple ? A .... see all the js workaround at manual.

Agree.

If this field should replace the usage of Javascript in the questiontext field, the javascript field should be available for each language.

The mental model of developers "don't repeat yourself (DRY)" is fine as long as the abstractions are 100% correct in all current and future uses cases. I prefer duplication of code over wrong abstractions.

I'm not able to overlook every usercase around language strings in javascript. So having a field for every language covers future user cases fine.
What are the aims of introducing such a JS field.
To me:
1.) Reducing the current issues with getting Javascript code destroyed when editing the question text.
2.) Showing the extra code without entering the questiontext field itself
3.) Getting the JS code separated from the question text will help to suppress this code when printing/exporting questiontexts.

Wrong abstraction is more pain than duplication of code. We can sense that with certain question types when the user case changes slightly. With strong abstraction complete refactoring is often the only way. Copying the question type with less code would have allowed quicker progress at the cost of duplication of code.

Example from other platforms how they handle adding Javascript to a question.
https://www.qualtrics.com/support/survey-platform/survey-module/question-options/add-javascript/

First thoughts on UI for this: you could of course have a check box (default checked) that indicates: Javascript identical for all survey languages (only if the survey has multiple languages).

If the user unchecks the checkbox, Javascript must be defined per language...

Common way of working: first define Javascript with the checkbox checked and uncheck if neded, which leaves you with identical Javascript for all languages, which you can adapt per language.

«If this field should replace the usage of Javascript in the questiontext field, the javascript field should be available for each language. » and you have so many user who update JS for first language and don't remind to put or update for other language …
Real situation, real case … survey tested and tested again and again … launch … 2 weeks after : Arg … js in chines is not updated …

@DenisChenu: I'd rather see here one JS field for all languages to avoid the situation as described by you.

Any JS script can be easily amended to behave differently for each language (remember that LImeSurvey provides the currently language in a JS variable by default).

@c_schmitz : for information : i added an option to set script after answers.
About language : i really think it's better without

@DenisChenu, don't we have such a ("Separate input field for Javascript in question editing") feature at LS 4 now?

Yes, but mine still working on 4.0 and are same for all language :)

I think one field for all covers 99% of all cases.

If needed for different languages, can't we just use script code like this:
if('{LANG}' == 'en')
{
do this
}
elseif(('{LANG}' == 'fr')
{
do that
}
else
{
do something else
}

Then : can close

I still prefer a JS field for every language.
I prefer duplication of code over wrong abstractions.
I'm happy that we have an EndURL for every language and not someone saying "You can do that via ExpressionScript and change the URL if the language is different". Wouldn't work anyway, cause ExpressionScript is broken inside EndURL.

But user will vote with their feet. The customers of Denis and Mazi will ask them to adapt the code.
The Saas users will ask the LimeSurvey Support ;-)

@jelo: I appreciate the feedback. In the end though we build features for 99% of our users.
Also, having one JavaScript field per question does not prohibit the possibility for a language-related one in the distant future.