Pipe escape enhancement
OpenPublic

Description

Author: mitchell_neill

Description:
Hi.

I am entering this after seeing a question posted on the mailing list about having tables within SF text fields.

There is an extension called PipeEscape that allows for pipe characters in parser function arguments avoid being interpreted as an argument delimiter. This works great if manually used in SF text fields.

Would it be an idea to have this code actually incorporated into SF forms? In this way you can have tables, galleries etc in SF text area fields without the user having to manually insert (or even being aware of) the PipeEscape extension markup.

Cheers
Neill.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30042

bzimport set Reference to bz34613.
bzimport created this task.Via LegacyFeb 23 2012, 12:16 PM
bzimport added a comment.Via ConduitFeb 23 2012, 12:33 PM

mitchell_neill wrote:

I'm probably talking nonsense re. SF aren't I. I guess if this should be an SMW enhancement.

Neill.

bzimport added a comment.Via ConduitFeb 23 2012, 12:34 PM

dvdgmz wrote:

It seems me a useful feature.

Maybe the fields can have a 'pipeescape' parameter:

{{{field|MyField|pipeescape=true}}}

Another approach could be having parameters to put content in the field value before and after the content entered by the user:

{{{field|MyField|before=|after=}}}

In this case we can put:

{{{field|MyField|before={{#!:|after=}} }}}

resulting:

{{MyTemplate

MyField={{#!:

Content introduced by the user
}}
}}

and perhaps this could be useful for other cases.
But I don't know if is something difficult to implement.

  • dvdgmz.
bzimport added a comment.Via ConduitFeb 23 2012, 1:12 PM

mitchell_neill wrote:

No, actually this is a SF problem as well.

It is all very well wrapping the text field in the template with the pipe escape, but next time you edit with form the entered text will get busted if a pipe char is present. So you have to have the pipe escape parser call actually in the field meaning the users have to be aware of it and how to use it. This is not ideal.

So, the SF parser would benefit from pipe escaping text fields.

Cheers
Neill.

Yaron_Koren added a comment.Via ConduitFeb 23 2012, 2:19 PM

dvdgmz - both of those syntax ideas you suggest sound useful. Especially the second one. I'm always afraid to make the SF template-parsing code any more complicated than it already is, but in theory, I think that's a good idea.

bzimport added a comment.Via ConduitFeb 23 2012, 3:13 PM

mitchell_neill wrote:

The before and after idea would be really useful. I could see that being used for all sorts of things :)

A pipescape parameter might be simpler to implement though ;)

bzimport added a comment.Via ConduitFeb 25 2013, 12:34 PM

alj62888 wrote:

I have properties that hold full text in it's values and has to handle any character. This is not just a pretty formatting issue; one single character that is inaccurate to what the user intends will break my process. I vote for this to be resolved.

bzimport added a comment.Via ConduitDec 11 2013, 4:51 PM

alex.g.muir wrote:

Yes I agree.. seems like it would be useful.. perhaps a simple fix would just be to convert the | [ ] into the html equivalent on upload or when saved through a form?

The html equivalent representations work but not on upload of xml.

bzimport added a comment.Via ConduitDec 11 2013, 5:51 PM

buba.bbojang wrote:

I agree with Alex. It would be great if the html equivalent representations works on xml upload...

Anyway, getting it fixed without making it more complex than it is, is more important. So I vote for it.

bzimport added a comment.Via ConduitDec 12 2013, 3:28 PM

mitchell_neill wrote:

Ordinary users can't be expected to "double-escape" the relevant characters, by replacing "{" with "[", and so on.

Surely this can be sorted with a small code tweak?

Thanks.

bzimport added a comment.Via ConduitDec 13 2013, 3:06 PM

alex.g.muir wrote:

(In reply to comment #9)

Ordinary users can't be expected to "double-escape" the relevant characters,
by
replacing "{" with "[", and so on.

Surely this can be sorted with a small code tweak?

Thanks.

Yeah I'd agree with that the average user that will be editing the forms manually shouldn't have to know how to do this.

Which php files would need to be edited to add this logic? I was thinking just to add the feature on my side here.

Yaron_Koren added a comment.Via ConduitDec 13 2013, 4:05 PM

Just to clarify, the double-escaping is only needed if you're doing an XML import - due, I assume, to some sort of bug in Special:Import.

bzimport added a comment.Via ConduitDec 14 2013, 8:51 PM

alex.g.muir wrote:

It's probably a normal feature of an xml parser to convert the html entities to ascii.

Inserting in the interface one does not need to double escape.

Add Comment