Hi ff7cbaf6d4e6

Are you talking about 6.13.5? if yes, then it doesn't support utf8mb4 and won't do it in future.
However, meaningful error messages will be provided soon on 6.13.x by way of backporting fixes.

Also, please see the following item for utf8mb4 support: https://jira.atlassian.com/browse/CONFSERVER-53642

Thanks,
Ganesh

Hi philippe.perez, we got the same error with 6.18.5, can I update mysql setting to UTF8MB4?

In doc, it says only confluence with 7.2 or later version can upgrade. Confuse...

Hi philippe.perez, We are looking into backporting the meaningful error messages to 6.13. We will update this ticket once that is completed. Unfortunately, if you are interested in full emoji support in MySQL you will need to upgrade to 7.3 or our upcoming Enterprise Release 7.4. 

Hi All,

I wanted to follow up on our update above. The Confluence server development team has now completed both item 1 (Support for emoji in MySQL) and item 2 (providing meaningful error messages). We strongly encourage customers to follow the steps outlined in our documentation to migrate from UTF8 to UTF8MB4, completely resolving this issue.

If you are unable to migrate to UTF8MB4 we have added a number of meaningful error messages to Confluence to stop users attempting to add unsupported 4-byte characters. We have added these errors to:

• page publish/save events for pages and blogs 
• page titles
• comment/inline comment saves.

Please note that we have not added this error message to content fields that are less used/less likely to contain 4byte characters including:

• comments accessed via email,
• the editor in Questions for Confluence,
• comments on attachments,
• gadget comments,
• attachment titles
• content added via Confluence Mobile. 

From the Confluence development team, we want to say thank you for everyone who provided feedback as part of both of the fixes mentioned above. We hope you now enjoy an emoji-filled Confluence. 

Regards,

The Confluence Server Team

Atlassian Update - Feb 2020
We have been working on a fix for this issue and wanted to give you an update on where we are up to. Our work in broken down into two key milestones:

1) Support for emoji in MySQL: We have delivered support for UTF8MB4 in Confluence 7.3.1. This work was being tracked in CONFSERVER-53642 - Support MySQL Databases using utf8mb4 and is now Done. Confluence now supports 4 byte unicode characters with MySQL UTF8MB4 collation. To assist customers with existing MySQL databases (that do not support UTF8MB4) we have provided a detailed guide outlining instructions on how to move to a UTF8MB4 compatible MySQL database here.

2) Provide meaningful error messages when adding emoji on instances still with MySQL utf8: To stop users attempting to add unsupported Emoji to Confluence with MySQL utf8, we have added verification to publish/save events for all pages and blogs. This will provide users with a useful message instructing them to remove the character in order to save their content. We expect the message to look something like this:

We have released this change as part of 7.3.1 and will backport this change to the next bugfix release of 6.13 as well. Note we also plan to add this error message to emoji’s included in page titles, comments, inline comments and attachment comments. These will be added in future bugfix releases as they become available. You can continue to track this work in this Jira ticket.

Cheers,
The Confluence Server Team

Works for me as well.  Here's how to update your database.  Stop confluence then update my.cnf:

[client]
default-character-set = utf8mb4
[mysqld]
character-set-server = utf8mb4

Reload or restart mysqld.  Next update all of your tables (there are many):

mysql> SET FOREIGN_KEY_CHECKS = 0;
mysql> ALTER TABLE <all of your tables> convert TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
mysql> SET FOREIGN_KEY_CHECKS = 1;

Start confluence.  Process is similar for Jira - change your database driver from mysql to mysql57 first.  Enjoy 💩

I upgraded to Confluence 7.3.1 and had already used MySQL 5.7.29. 

Good to know.

That means that you also upgraded to Confluence 7.3.1 and your database was in 5.9 ?

Did an update yesterday and it worked fine. Don't forget to update database, tables and columns.

https://confluence.atlassian.com/confkb/how-to-fix-the-collation-and-character-set-of-a-mysql-database-670958160.html

Is this really fixed now? Confluence 7.3.1 is already released but the status of this ticket is still in progress.

Not sure what you call "the real issue", but if you mean the support of utf8mb4 for the database, then it won't prevent the need of the warning message, unless you intend to migrate your database or convert it (which will likely be a pain).

100% agree, this is a misleading message that might cause a user to investigate switching database backends.  A better message would be something like "Confluence does not support the 😀 character."

Hopefully the real issue is being resolved and time isn't being wasted on implementing a warning message...

Not really that important but I think that screen shot is a tad misreading 

It says "The character isn't supported by your database", kind of unfairly throwing mysql under the bus.  A more sincere prompt would be "confluence don't support this character with your database"

Anyway, just saying, super happy that there is progress on this ticket and as long as the solution will be available soon, that error message would be very temporary anyway, so not a big deal

martin.boehme It should be visible now. I have attached a local copy.

msaxby The screenshot is anywhere in an internal Slack and most of us will be unable to view it

Atlassian Update - Jan 2020

We have been working on a fix for this issue and wanted to give you an update on where we are up to. Our work in broken down into two key milestones:

1) Provide meaningful error messages when adding emoji: To stop users attempting to add unsupported Emoji to Confluence we have added verification to publish/save events for all pages, blogs and page comments. This will provide users with a useful message instructing them to remove the character in order to save their content. We expect the message to look something like this:

We are planning to release this change as part of 7.3 and will backport this change to the next bugfix release of 6.13 as well. Note we also plan to add this error message to emoji’s included in page titles, inline comments and attachment comments. These will be added in future bugfix releases as they become available.

2) Support for emoji in MySQL: We have started work on adding support UTF8MB4 in Confluence. This work is being tracked in CONFSERVER-53642 - Support MySQL Databases using utf8mb4 IN PROGRESS. Please watch or vote on this issue if you are interested in full support for UTF8MB4. This is planned for release soon but will update the suggestion as we continue to make progress. To assist customers with existing MySQL databases (that do not support UTF8MB4) we will provide a detailed guide outlining instructions on how to move to a UTF8MB4 compatible MySQL database.

Cheers,

The Confluence Server Team

Hi All, 
A detailed status update on the support of utf8mb4 and utf8 emoji error handling is scheduled for this week. Please keep watching this issue for the same.
Thanks, 
Ganesh

The issue has been in progress since Aug 2018, way before Confluence 7 release. I would not hope a resolution is in sight based on the issue status.

In fact, CONFSERVER-53642 might be what really needs to be fixed I'd say...

Would indeed be nice if this will be resolved in next Enterprise Release, at this moment running multiple databases because of this.

(servicedesk won't start if you don't have the character-set-server=utf8mb4
collation-server=utf8mb4_bin set)

Since the issue itself is in progress I hope that it will be resolved until the next Confluence Enterprise Release.

Any idea when this will be fixed?  The utf8mb4 character set is not even remotely new, I'm confused why this is still not resolved.

This issue is currently blocking our migration to another Database Backend. Due to the lack of utfmb4 support we are unable to Import our XML Backup to the new site. 

After talking to Atlassian Support we only get the glorious answer to use the XML Cleaner. After cleaning the import works, but - big surprise - all emojis used by our customers are gone and no saving of a page with emojis is possible. This is definitely nothing we can tell our customers.

We're almost approaching 2020, so please fix this issue and get proper support for utf8mb4

We see plenty of users not able to store their recent page versions because of multibyte characters copied in. This causes that they are just continue to work with the draft version of their pages for several weeks. Means they hold the actual state of their pages just in the synchrony store. And this makes it impossible for us even to switch to postgresql because we can not export that data.

Please fix this issue, give us an idea how to enforce a saving of all open drafts afterwards as Admin for all pages. We understood that upgrading to version 7 would mean to loose all that page data our customers rely on because synchrony store will wipe. So we are screwed now.

Please, with double chocolate!

Could we please shorten the "short term" of this ticket ?
It's a real pain for support team to explain again and again that Confluence is working despite the message.
This gives a really bad image of the application to our users

Upgraded to 7.0, same old issue here. Please release a patch recently to make this work team.

If Jira and confluence use same MySQL DBMS, that is important to use utf8mb4. Check it please.

+1, asking for status update for the 3rd time. 

+1

Please update the status of this issue; 7.0 was released in the meanwhile and there is no news here.

"This is in our short-term backlog and we expect to work on it next" was posted 10 months ago.

What is the status of this fix?

This bug has a confusing title. MySQL 5.6 and 5.7 do support databases with UTF8mb4 character sets.

However Confluence 6.15,7 and older versions can only be installed on MySQL databases with UTF8 (3 bytes) character sets.

Please fix this in Confluence!

There are 10 issues in my company about this, all reported to the people operating our Atlassian products, who cannot do anything to fix it. Please address this.

When click the save button, and it went wrong as bellow:

error: [com.ctc.wstx.exc.WstxLazyException] Unexpected close tag ; expected . at [row,col \{unknown-source}]: [1,328]

The most frustrated is that we can't find the content. So can Confluence program do something like Interceptor? Maybe Confluence plugin development is a way?

If Atlassian won't add UTF8 support for 7.0 it probably won't happen for a 7.x minor release either. So the next chance would be 8.0 which is probable three years or more into the future. So ditch MySQL 5.6 support and please fix this with 7.0.

Can you give us a updated statement for this issue please?

I fully support the above comments. We have a relatively small instance with 2k users compared to other customers here  but our users also regularly run into this error. It is really annoying and what's even worse: in 2019 there is still enterprise software that can't handle 4 Byte UTF-8 chars even if the database itself supports them. Come on Atlassian, you finally fixed that for Jira and Crucible  now do this for Confluence, too!

But not just in some Confluence version >= 7.1, put it in 7.0 since it's a platform release.

Also very common complaint for us on 10,000 user instance.  Very frustrating bug especially because of the misleading error message. Our users hit this bug every few weeks so we continue to spend our own time helping them with the workaround. It's frustrating and wasteful.

Here is a recent yammer post from one of our frustrated users:

 
Hi all, just sharing this here in case someone has experienced a similar issue. Today I started having problems to save a confluence page on my desktop computer. I was getting this banner popping up every time I clicked 'Update', saying:

"Unable to communicate with server. Saving is not possible at the moment."

Which was really odd because I was able to save other confluence documents. I then opened this document in a conference room computer and had the same issue, not being able to save. Weird? Came back to my office planning to submit a ticket and decided to check a few things before I did that, like, checking the content I had inserted this morning in the page.

All the sudden I noticed a pretty 'harmless' smiley face I had copied-pasted from an email. Let's try to delete it, I thought. Deleted it. Clicked the 'Update' button. It worked!

Great. So from here, I learned 2 lessons:

1. Inaccurate error messages are really annoying and lead you to the wrong path. Why "Cannot communicate with the server?". Can't confluence detect I have put some element in the page they cannot handle and tell me that instead? It would have been much easier to troubleshoot.
2. Beware users out there, even thought these emoticons may seem inoffensive and pretty-looking, they may break your Confluence page

We're officially over 6 months on the short term backlog Atlassian team, can we please get some status update here?  This is my #1 most common user complaint on a 5000 user instance. 

I'm trying to figure out if I need to go ahead and prioritize work to migrate to postgres, or if this is getting handled in a new version and I can just get new features instead of doing that extra db migration work.

Considering that other products now actually support the relevant utf8-mb4 encoding, if there's some reason we can't expect to see that in confluence as well, the transparency will be appreciated so we know how to prioritize our work.  I've been assuming this would come to confluence too but knowing if that isn't the case is still helpful, if somewhat disappointing.

Wondering if this will be on Confluence 7.0 at least.

https://confluence.atlassian.com/doc/preparing-for-confluence-7-0-950280675.html

Not in above list though

Just wasted a ton of time trying to figure out why blog posting stopped working - the culprit was a single emoji copied over from MS. So with proper messaging instead of the very generic error I got, could have been a 2 second fix!

We now run the latest versions of Fisheye and Jira that support MySQL UTF8mb4 and emoji's work fine (4 byte unicode). Why is Atlassian not moving more quickly for Confluence - this lack of attention is negatively affecting customers worldwide.

Emojis got put into an office 365 group description and that caused a lot of users to be unable to sign into Confluence until we set the description attribute to cn instead of description.

Was hammering the Publish button today (confluence 6.2.3) for a loong time thinking it was a temporary network issue. Eventually realized through trial and error that it was the dang 🌟 emoji in my document preventing it. Upvote on this, and a clearer failure message.

I believe the summary should probably be different, since MySQL is clearly capable of handling 4 byte unicode but Confluence doesn't support it with MySQL.

Faced this issue while create/edit page in confluence 6.11.2 and MySQL 5.6.42

@ganesh

I'm a PM on Confluence cloud and I'm talking to our customer, Craig from IU, who wants to make sure that "handling this gracefully" means supporting utf8mb4 encoding. Jira and Fisheye have just implemented this, so he is hoping to see the same from Conf.

Any update would be super helpful! 

Thanks,

Hilary

Thanks for the update, Ganesh.

Our difficulty is that we adopted Atlassian's stack on MySQL given it's stated official support and that our IT team has standardized on MySQL and has no in-house Postgres experience.  If Atlassian was to drop MySQL support officially maybe it would motivate a change over to Postgres, or of course if they were to fix this problem, but otherwise we're kinda caught between the two.  I don't know how many other customers might be in a similar situation.

Thanks for confirming this is still broken in the latest versions, community.

IMO The only sane thing to do as an Atlassian customer is use postgres.  It's what they test on and is the only officially supported platform on AWS, at least for JIRA.

We have both mysql backed Jira and Confluence installs, and automation that pulls tickets from another system into JIRA.  The last time automation pulled a ticket with a smiley in from the other system, it took Jira down.

Other databases may work, but support is 2nd class for these platforms.

Atlassian, this is the kind of bug fix that should be getting prioritized for your next enterprise release.  Please save us the trouble of having to migrate a massive mysql db to postgres!!!

+

Atlassian Confluence 6.12.0 is also broken

+

Confluence 6.8.2 same problem

Is there any information on what the schedule/status of this issue is?

Any update on this feature? The comment on https://jira.atlassian.com/browse/CONFSERVER-34420 impliest that more information would be given about progress of this issue.

Jira will support that with 8.0 and so should Confluence, better all Atlassian products!