View Issue Details

IDProjectCategoryView StatusLast Update
11921Feature requestsSurvey editingpublic2019-05-21 14:28
Reporterc_schmitz Assigned Toc_schmitz  
Status closedResolutionfixed 
Target VersiondevelopFixed in Version4.0.0dev 
Summary11921: Separate input field for Javascript in question editing
DescriptionCurrently custom JavaScript needs to be entered in source code mode either in the question text or question help.
It would make sense to offer a separate field for entering JavaScript and store it in the database.

However the templates need to implement that additional field, too.
Additional InformationSome thoughts:
- A new field in question table needs to be added
- A new placeholder in the question template needs to be added: {QUESTION_JS} or similar.
- In the GUI the JS field should use a proper Javascript highlighter (and line numbers).
- The JS editor field should be hidden/collapse at first and only if it contains something it should be shown expanded on question edit from the start.
TagsNo tags attached.




2016-11-17 10:59

administrator   ~42020

@jelo @LouisGac @tpartner : Good idea?

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


2016-11-17 11:32

developer   ~42022

Easy way : just add a Plugin and register script in beforeQuestionRender . Quick system : let me 1/4 hour
In general : CClientScript::POS_END ?

Better system : a dropdown with 'register in HEAD/BODY/PAGELOAD etc ....'
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)


2016-11-17 11:44

administrator   ~42023

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.


2016-11-17 11:54

developer   ~42024

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.


2016-11-17 12:41

developer   ~42025

core plugin done in 5 minutes

To move to a core feature : do like css_class

A plugin can be deactivated


2016-11-17 13:13

developer   ~42028

Fix committed to develop branch:


2016-11-17 13:13

developer   ~42029

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


2016-11-17 13:16




2016-11-17 13:59

administrator   ~42030

Last edited: 2016-11-17 14:13

View 2 revisions

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.



2016-11-17 15:51

developer   ~42032

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 :)


2016-11-17 15:56

administrator   ~42033

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.


2016-11-17 16:08

developer   ~42034

Ah OK :).

Not for me then.


2017-02-02 13:10

partner   ~42937

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:


2017-02-02 13:12

partner   ~42938

Or more specifically at:


2017-02-02 14:09

developer   ~42939

Currently , with and 3.0/develop.


2017-02-22 09:03

partner   ~43060

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.


2017-02-22 09:36

developer   ~43061

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.


2017-02-22 09:38

partner   ~43062



2017-02-22 13:45

partner   ~43063

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.


2017-02-23 12:20

partner   ~43081

Example from other platforms how they handle adding Javascript to a question.


2017-02-23 19:47

partner   ~43083

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.


2018-10-04 14:48

developer   ~49237

«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 …


2018-10-04 15:23

administrator   ~49238

@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).


2019-04-19 16:47

developer   ~51542

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


2019-05-20 17:08

partner   ~51992

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


2019-05-20 17:10

developer   ~51993

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


2019-05-20 17:13

partner   ~51994

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
   do something else


2019-05-21 09:16

developer   ~51999

Then : can close


2019-05-21 14:13

partner   ~52011

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 ;-)


2019-05-21 14:28

administrator   ~52012

@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.

Related Changesets

LimeSurvey: develop e3eba983

2016-11-17 13:11:59


Details Diff
New feature 11921: Separate input field for Javascript in question editing
Dev: except for import: XSS is readonly for user with XSS
Affected Issues
mod - application/helpers/SurveyRuntimeHelper.php Diff File
add - plugins/addScriptToQuestion/addScriptToQuestion.php Diff File

LimeSurvey: develop 23b073ac

2016-11-17 16:10:23


Details Diff
Revert feature 11921: javascript question settings Affected Issues
rm - plugins/addScriptToQuestion/addScriptToQuestion.php Diff File

Issue History

Date Modified Username Field Change
2016-11-17 10:50 c_schmitz New Issue
2016-11-17 10:57 c_schmitz Additional Information Updated View Revisions
2016-11-17 10:59 c_schmitz Note Added: 42020
2016-11-17 10:59 c_schmitz Target Version => 3.0
2016-11-17 11:18 LouisGac Sticky Issue No => Yes
2016-11-17 11:32 DenisChenu Note Added: 42022
2016-11-17 11:44 c_schmitz Note Added: 42023
2016-11-17 11:54 tpartner Note Added: 42024
2016-11-17 12:41 DenisChenu Note Added: 42025
2016-11-17 13:13 DenisChenu Changeset attached => LimeSurvey develop e3eba983
2016-11-17 13:13 DenisChenu Note Added: 42028
2016-11-17 13:13 DenisChenu Assigned To => DenisChenu
2016-11-17 13:13 DenisChenu Resolution open => fixed
2016-11-17 13:13 DenisChenu Note Added: 42029
2016-11-17 13:16 DenisChenu File Added: Capture du 2016-11-17 13-16-14.png
2016-11-17 13:59 c_schmitz Note Added: 42030
2016-11-17 14:01 c_schmitz Note Edited: 42030 View Revisions
2016-11-17 14:01 c_schmitz Note Revision Dropped: 42030: 04975
2016-11-17 14:13 c_schmitz Note Edited: 42030 View Revisions
2016-11-17 15:51 DenisChenu Note Added: 42032
2016-11-17 15:56 c_schmitz Note Added: 42033
2016-11-17 16:08 DenisChenu Note Added: 42034
2016-11-17 16:08 DenisChenu Assigned To DenisChenu =>
2016-11-17 16:12 DenisChenu Changeset attached => LimeSurvey develop 23b073ac
2017-02-02 13:10 tammo Note Added: 42937
2017-02-02 13:12 tammo Note Added: 42938
2017-02-02 14:09 DenisChenu File Added: Capture du 2017-02-02 14-08-04.png
2017-02-02 14:09 DenisChenu Note Added: 42939
2017-02-22 09:03 tammo Note Added: 43060
2017-02-22 09:36 DenisChenu Note Added: 43061
2017-02-22 09:38 tammo Note Added: 43062
2017-02-22 13:45 jelo Note Added: 43063
2017-02-23 12:20 jelo Note Added: 43081
2017-02-23 19:47 tammo Note Added: 43083
2017-04-25 11:09 LouisGac Sticky Issue Yes => No
2018-10-02 15:44 c_schmitz Assigned To => Deusdeorum
2018-10-02 15:44 c_schmitz Status new => assigned
2018-10-02 15:44 c_schmitz Target Version 3.0 => develop
2018-10-02 15:44 c_schmitz Priority none => high
2018-10-04 14:48 DenisChenu Note Added: 49237
2018-10-04 15:23 c_schmitz Note Added: 49238
2019-04-17 09:55 c_schmitz Assigned To Deusdeorum => c_schmitz
2019-04-19 16:47 DenisChenu Note Added: 51542
2019-05-20 17:08 Mazi Note Added: 51992
2019-05-20 17:10 DenisChenu Note Added: 51993
2019-05-20 17:13 Mazi Note Added: 51994
2019-05-21 09:16 DenisChenu Note Added: 51999
2019-05-21 14:13 jelo Note Added: 52011
2019-05-21 14:28 c_schmitz Status assigned => closed
2019-05-21 14:28 c_schmitz Fixed in Version => 4.0.0dev
2019-05-21 14:28 c_schmitz Note Added: 52012
2019-11-01 17:25 c_schmitz Category Survey design => Survey editing