[kupu-dev] kupu html-escapes the contents of the <script> and <noscript> tags

Antoine Brenner pythonjob at gymglish.com
Mon Mar 17 19:18:38 CET 2008


Hello Duncan,

Thanks for your (very) quick answer.

Duncan Booth wrote:
> "Antoine Brenner" <pythonjob at gymglish.com> wrote:
>> Thus two questions:
>> 1) Is it correct that kupucontentfilters.js is to be modified ?
>> if yes:
>> 2) How should I modify kupucontentfilters.js so that the contents of the
>><script> and <noscript> tags are left unchanged ?
>
> Right now it's badly broken: every time you edit the noscript tag gets
> another level of escaping. Unfortunately I don't think it is easy to fix.
>
> [...not so easy solution...]
> And of course when editing with kupu you'll see the content of the
> <noscript> tags as raw HTML because that's what it is.
Sure.

> You can't edit <script> tags inside kupu anyway as they are invisible.
In the 'html source' mode, I can see and edit them in my kupu though.
(but the contents are escaped like <noscript>)

> I'd suggest that if you really need <script> and <noscript> you simply
> turn  off kupu for those documents [...]
This is not an option for me, I need a visual editor, and kupu is very
good.

On the other hand, I do not have many flash possibilities (a dozen or so),
and I figured out a way of using portal_transforms to replace 'magic
strings' like {{flash=something}} on the fly with the contents I want.

This implies using the archetypes field like this:

TextField('text',
              required=True,
              searchable=True,
              primary=True,
              storage =
Products.Archetypes.public.AnnotationStorage(migrate=True),
              validators = ('isTidyHtmlWithCleanup',),
              default_content_type="text/html",
              allowable_content_types=("text/html",),
              # Make sure that text/html is in allowable_content_types if
you want kupu to be used.
              default_output_type="text/gghtml",  # This is where the
magic is done: calling here.getText() will return
text/gghtml.
              # The transform text/html -> text/gghtml will replace the
{{flash=something}} strings with the <script> and <noscript>
tags and their contents as we want
              widget = RichWidget(
                        description = "",
                        description_msgid = "help_body_text",
                        label = "Body Text",
                        label_msgid = "label_body_text",
                        rows = 25,
                        i18n_domain = "plone",
                        allow_file_upload = True )
             ),
    )


Since the field 'text' is in text/html while stored in the zodb, when the
users edit the page, they will see {{flash=something}} everywhere where
the flash is, but when the page is in view mode, the {{flash=something}}
will be replaced by the <script>...</script> <noscript>...</noscript>
that we want by the transform because of the default_output_type.

This is not a generic solution, but since we have a limited number of
flash animations, this looks much easier to do that what you suggest
in order to have kupu not escape the content of <noscript> tags.

Note:
Initially, I wanted the text/gghtml to be the content type edited by my
users (with the {{flash=something}} strings) but if I did this, I could
not have the users edit the contents with kupu because kupu will only be
used for text/html (because of isKupuEnabled() in plone/plonelibrarytool.py
I guess). So I ended-up keeping text/html in edit mode (even though it is
'special') and displaying text/gghtml by default (instead of text/html)
even though this one is the real html...
This is not a big problem, but making an option in the widget to specify
whether you want to force the use of kupu or not would probably have been
cleaner. Just my 2 cents...


Anyway, thanks a lot: I have no more doubt about my choices now... I will
go the portal_transforms way.


Best regards,
Antoine Brenner

--
Antoine Brenner

GymGlish
http://www.gymglish.com - http://www.delavignecorp.com



More information about the kupu-dev mailing list