#646 Escaping error in HTML export

[Stéphane Aulery]

Hi Mark,

I find some fields of Miscellaneous type not escaped in HTML export (Publisher, Medium, Authors).

Regards,

[Mark Grimshaw]

. . . but perhaps my latest fix accomplishes the task without substitution or need for another function. It might be helped with {1} in it. If it's fine, I'll remove the print statements and commenting.

[Stéphane Aulery]

Not botter. It's an edge case. Let's save this for later and continue.

[Mark Grimshaw]

OK. I'll save the code as is with comments in case it is needed later. But I'll improve the multiple punctuation detection because it does need to account for HTML entities elsewhere.

[Stéphane Aulery]

If at the time of release there are still things to correct, we will close this ticket and open a second ticket with more precise information on the remaining error.

[Mark Grimshaw]

Hi Stéphane,

I have no problem with tinyMCE—I know it's fine. What I want to know is, when loading a resource into the edit interface's text inputs (not textareas), should I escape what comes from the database?

i.e. & in the database becomes &in the text input and thus is saved back to the database as &.

This is what happens currently but seems wrong to me because the user might have entered & quite deliberately in the text input to begin with.

If what we are doing is wrong, then I should also check other text input interfaces such as editing keywords, creators, collections, publishers, etc.

If there are issues with imports, then that is another issue.

Mark

[Stéphane Aulery]

I checked. Yes "My & test 2" in the database is displayed "My & test 2" in the resource form. It's wrong. Thext should be displayed in input and texarea is ain the database. TinyMCE is a special case.

Perhaps there are some case where $value should be escaped in textInput(). In which case, we should write a textInputRawValue() and use that explicitly in RESOURCEFORM and elsewhere.

[Mark Grimshaw]

Great. I will check throughout.

[Mark Grimshaw]

The solution that I can see is that \FORM\_inlineHtmlAttribute() in \form\textnput() should not be applied to $value because that escapes $value (which is not what we want).

[Stéphane Aulery]

Hum. No, it's because I made this found universal by not double escaping but the value the should be escaped regardless to retrain the original value. I still need to fix the escaping of value attribut.

[Mark Grimshaw]

My edit disappeared.. . . I added that perhaps a textInputRaw() should be added and explicitly used in RESOURCEFORM and elsewhere where escaping of a value from the database is not wanted.

Other than that, don't know what else to suggest if we don't want textInputs to escape data from the database.

[Mark Grimshaw]

. . . and your latest fix does it.

[Stéphane Aulery]

Escazping is always a headache.

[Mark Grimshaw]

Agreed!