Hello!
While using the Confluence Migrator Application (Pro), I noticed that importing emoticons is not working as expected. The formatting of confluence exports seems to have changed.
The initial implementation was Tracked in CONFLUENCE-146 (Loading...). There were additions after the initial implementation, but the current implementation still expects a format like this:
<ac:emoticon ac:name="smile" ac:emoji-shortname=":slight_smile:" ac:emoji-id="1f642" ac:emoji-fallback="🙂" /
But when exporting from the current Confluence cloud version, the exported format is like this:
<ac:emoticon ac:name="cross" ac:emoji-shortname=":cross_mark:" ac:emoji-id="atlassian-cross_mark" ac:emoji-fallback=":cross_mark:" />
Notice the change in ac:emoji-id and ac:emoji-fallback
For some reason, the new format is already mentioned in the original issue CONFLUENCE-146, but not tested inside the test of the implementation.
As seen in the code at confluence/confluence-syntax-xhtml/src/main/java/org/xwiki/contrib/confluence/parser/xhtml/internal/wikimodel/EmoticonTagHandler.java at d68bdf76dd8dd9cd14c6d5aa24752708433b4098 · xwiki-contrib/confluence · GitHub, the current implementation parses the emoticon properties in the following order: emoji-fallback, emoji-id, shortname, name. This worked for the old confluence format, as the emoji-fallback seems to always have contained a properly formatted emoji and the emoji-id was always a Unicode code point of the emoji. However in the new format, these got replaced by strings that are similar to the name property.
When importing into XWiki and using the first format this results in the Text “
” and when using the newer format it results in the Text “:cross_mark:”, but should result in “
”. This is because the fallback is evaluated first and was expected to contain the emoji as Unicode text.
There are multiple solutions to this, but I think the most robust would be to check while parsing the fallback inside sendFallback and check whether it is an emoji or a label like string. If it is a label, sendFallback should fail and the other methods are tried. The function sendEmojiId should work as expected, because the label should not get interpreted as a valid Unicode code point. It may be beneficial to also check inside sendEmojiId if the parsed code point is an emoji to be on the safe side. Besides the modification of sendFallback and sendEmojiId, it would also be good to switch the order of parsing to sendName, sendShortName, sendEmojiId, sendFallback, as in the official documentation for the Data Center version of Confluence, only the name field is mentioned: Confluence Storage Format | Confluence Data Center 9.2 | Atlassian Documentation
7 posts - 3 participants