Style definition in Wiki pages no longer works

I think I've seen this raised already in JIRA, but if you can't find it please raise another bug.

Thanks,
Mike

fjdoyle

Has it been confirmed that there is an active bug report and that this is being addressed?
The sudden loss of formatting on wiki pages after upgrade has caused some distress.

zorin1st

Hallo,
same problem here, but it is not only in the wiki, the missing style information is in the blog too.
If i check out the sites vom alfresco explorer for offline editing, all style information is correctly in the file.

Even it is possible to add and save new inline style information from TinyMCE in Share.

It seems, that only the file input parsing for displaying the files from Share is wrong.

I hope someone can solve this bug soon, i dont want to downgrad to 3.2 since i got the Records Management working fine in 3.2r…

thank you for helping 🙂

best regards, Elmar

fjdoyle

Seriously guys…is somebody looking into this? The only official response was, "I think maybe I saw a JIRA on this…but if not you should submit one". I asked if it was being pursued and received no response, so I joined the JIRA site and submitted it myself (after searching to see if there was already a submission…which I did not find) and have heard nothing from that either. I realize this is the community edition and Share is a fairly new tool, but the wiki is a pretty significant part of the "collaboration" tool and the fact that the WYSIWYG editor completely deletes table cell borders and color formatting is a more than a little problematic.

Apologies, I hadn't spotted either the forum update or the JIRA issue (the latter hadn't been marked as "Share"). https://issues.alfresco.com/jira/browse/ALFCOM-3705

We're ramping up v3.3 development now, so I'll make sure it's addressed as soon as possible. If I get time to see where the issue lies in the meantime, I'll update the JIRA ticket.

Thanks,
Mike

zorin1st

@fjdoyle

i'm sure the editor does not delete the table style. If u open the file in alfresco explorer, u will see, all style information is there.
It's "just" a display problem

best regards, Elmar

fjdoyle

As this is a functional description of user experience, I would consider the lack of "applied style" to be a deletion.
In terms of it being a display issue, that would imply that the correct style info is present but the rendering system (i.e., browser) is not interpreting properly.
That is not the case. Applying new formatting (cell borders, bg color, etc) to new tables in the WYSIWYG does not result in production of correct HTML.
Existing table cells from previous Alfresco version wiki that had such formatting, have class tags with values such as "xl119". Assumedly, these were defined in a stylesheet that did not migrate with the upgrade or that is no longer being properly referenced. In either case, the assertion that the "style is still there in the editor" is wrong. Any such cell formatting from previous version or newly applied is not reflected in the editor.

We are having this exact same issue. It does need to be addressed, as it has caused somewhat of an uproar here since wiki pages are heavily used as a "Table of Contents" for different sites.

jocke

We also have the same problem. Is there a temporary fix of some sort until the next version comes out? It's very hard using the wiki at all without styling.

I took a quick look at this. It's due to the stripUnsafeHTML() function in stringUtils being updated to a third party solution. I guess it's stripping too much now.

[update] Note this is only a workaround. The style attribute is open to XSS attacks in Internet Explorer. We'll look at putting TinyMCE in a different mode to use css classes instead of the style attribute.

The workaround is as follows…

Create the following folder structure for the Tomcat where Share is deployed:

shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/wiki‍

In the wiki folder, create a file called page.get.config.xml containing the following:

<wiki>
   <allowUnfilteredHTML>true</allowUnfilteredHTML>
</wiki>‍‍‍

If you had the web-extension folder before this fix, you should just be able to reset Share web-scripts, otherwise restart Tomcat in order for the extensions classpath to be picked up.

Thanks,
Mike

That does the trick for the formatting. Thanks a lot.

Any idea when the Share dashlet problem might be fixed?

This:

[img]http://imgur.com/A3Hee.png[/img]

Good point! Do the same thing for the dashlet, but using:

shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/dashlet‍

In the dashlet folder, create a file called wiki.get.config.xml containing the following:

<wiki>
   <allowUnfilteredHTML>true</allowUnfilteredHTML>
</wiki>‍‍‍

Thanks,
Mike

This issue has now been resolved (without a work-around). Latest code in HEAD (for 3.3 release) and will also be available in the 3.2.1 Enterprise service pack.

Thanks,

Kev

This is broken again in 3.2r, even with the work-around in place. I've restarted Tomcat several times and it just refuses to work. Any ideas?

It was not fixed in 3.2r - as per my post above. It will be available in 3.2.1 (Enterprise) or 3.3 Community or current HEAD codeline. I haven't tried the workaround so I can't comment on that.

Kev

Thanks for the info. Any info on a release date for 3.2.1 Enterprise?

In the interim..it would be nice to get the workaround working again.

I dug around a little in the webscripts and found what it was calling.

File: org/alfresco/components/dashlets/wiki.get.config.xml

Changed the value to true and that fixed it.

analyzediz

Along the same lines, I'm not quite sure the logic behind not including <pre> tags as one of the safe HTML tags. I was looking at org.alfresco.web.ui.common.StringUtils and sure enough it was excluded from the list.

I'm trying to add the capability for users to post code samples into the tinyMCE control. I have created a plugin that work just as expected and when I save my edited content it makes it all the way into Alfresco. I know this because I can preview the content from the Alfresco Web Client. But once retrieved, the stripUnsafeHTML calls in out of the box FreeMarker templates just discards the <pre> tags. Is there a minimally invasive approach to extending the behavior of this class to allow additional html tags to be cosidered "safe"?

Thanks for any pointers.

I will update the whitelist to include PRE for 3.2.1E/3.3, from my investigations and testing it is safe to include. There is no way to add tags to the list via config yet - it is something we can look at adding, if you raise a request in JIRA.

Thanks,

Kevin

analyzediz

I will update the whitelist to include PRE for 3.2.1E/3.3, from my investigations and testing it is safe to include. There is no way to add tags to the list via config yet - it is something we can look at adding, if you raise a request in JIRA.

Thanks,

Kevin

Thanks Kevin, for the prompt response. I look forward to these updates.

Cheers.

rakmun

Having the same problem, any solutions?

Fixed in 3.2.1 Enterprise service pack.

You will need to reapply formatting to the posts with the editor, it does not fix previous posts. You can blame IE6 security flaws for this unfortunately. We cannot allow embedded STYLE tags so TinyMCE integration has been tweaked to generate safe FONT tags or similar.

Cheers,

Kev

marfarma

I'm implementing Community 3.3g and find that blockquote html tags are being stripped from the wiki pages.

I've tried indenting a block of text via the TinyMCE editor alternately using the quote and the indent editor buttons. I've confirmed that TinyMCE inserts a blockquote tag in either case. I've then confirmed that the saved wiki pages have been stripped of blockquote tags.

Can it be added to the whitelist as was done for the pre tag? From what research I've done, it appears to be safe. (htmlpurifier.org whitelists it. See: http://htmlpurifier.org/live/smoketests/printDefinition.php)

Yes that can be added.

Kev

I can get this to work in 3.3g using the workaround for wikis (still not fixed out of the box), but no matter what I try it doesn't seem to work for the dashlet.

Any ideas of what I can try to get the dashlet to display wikis correctly?

I've just tried the latest HEAD build and it works in the dashlet. I've also added BLOCKQUOTE to the tag whitelist.

Kev