Bug: Emojis force editors to log out on save

I find this very amusing in practice. :smiley: But, I assume the issue is boring in reality. :pensive:

I had a student club submit an event with this name: “Marketing Club’s First Event :tada:”. Whenever I make edits to it and save, the content is saved successfully, but I am then immediately logged out.

Looking at Debug/Errors, each time this occurs, the following appears:

04-Sep-2025 2:22:45pm CDT America/Chicago PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in /.../livewhale/class.livewhale.php on line 971

I tried to remove the party emoji (:tada:) from the title: no issues on save. If I add it back in again: time to log in again. :upside_down_face:

Looking at the event’s edit history, it appears the content might also be saved somewhere in an odd format:

Mostly a bug report. It’s not a significant issue for us – unless the Marketing Club sets a new trend – but also sharing for general awareness. :innocent:

Thanks,
Nick

@mischlern What LiveWhale version are you on? I stumbled on this exact bug when I was testing 2.20.0 back in May. But before we got around to updating, LiveWhale released 2.20.1, and then it seemed to be fixed.

Not sure if 2.20.1 specifically addressed it or if something else was at play. But I can tell you that it works for me now. FYI, we are on 2.20.2 now, but my notes show that the issue went away in 2.20.1.

We’re on 2.20.1 at the moment… :thinking:

I did try looking at the Release Notes initially, but not finding anything obviously related, I figured it was at least somewhat fresh.

Once again, I have to remember to try dev. :sweat: Seems to work fine for 2.21.1 at least, but I’m still seeing a “livewhale_revisions” error, and it also appears that any instances of events with emojis are not saved in revision history.

05-Sep-2025 9:28:56am CDT America/Chicago LiveWhale Error: /livewhale/?events_edit&id=28579 Incorrect string value: '\xF0\x9F\x8E\x89";...' for column 'revision' at row 1(INSERT INTO livewhale_revisions (id, pid, uid, type, date, revision, search) VALUES(NULL, 28579, 7, 'events', NOW(), 'a:70:{s:7:\"item_id\";s:5:\"28579\";s:13:\"last_modified\";s:19:\"2025-09-05 09:28:22\";s:9:\"last_user\";s:4:\"Nick\";s:4:\"mode\";s:0:\"\";s:3:\"eid\";s:0:\"\";s:11:\"change_mode\";s:1:\"1\";s:10:\"gallery_id\";s:0:\"\";s:9:\"thumbnail\";s:0:\"\";s:5:\"style\";s:0:\"\";s:16:\"remote_image_url\";s:0:\"\";s:20:\"remote_image_caption\";s:0:\"\";s:14:\"thumbnail_only\";s:0:\"\";s:16:\"cropper_image_id\";s:0:\"\";s:19:\"cropper_coordinates\";s:0:\"\";s:6:\"upload\";s:0:\"\";s:5:\"title\";s:35:\"Marketing Club’s First Event 🎉\";s:4:\"slug\";s:40:\"28579-marketing-clubs-first-event-127881\";s:18:\"slug_is_customized\";s:0:\"\";s:10:\"is_starred\";s:0:\"\";s:9:\"is_shared\";s:1:\"1\";s:4:\"date\";s:10:\"09/17/2025\";s:9:\"date_time\";s:7:\"12:00am\";s:8:\"timezone\";s:15:\"America/Chicago\";s:15:\"timezone_format\";s:2:\"us\";s:5:\"date2\";s:0:\"\";s:10:\"date2_time\";s:0:\"\";s:10:\"is_all_day\";s:1:\"1\";s:7:\"repeats\";s:0:\"\";s:13:\"repeats_every\";s:1:\"1\";s:12:\"repeats_from\";s:10:\"09/17/2025\";s:13:\"repeats_until\";s:0:\"\";s:19:\"repeats_occurrences\";s:0:\"\";s:7:\"summary\";s:46:\"<p>Marketing Club’s First Event 🎉</p>\";s:8:\"location\";s:0:\"\";s:9:\"places_id\";s:0:\"\";s:15:\"places_latitude\";s:0:\"\";s:16:\"places_longitude\";s:0:\"\";s:14:\"places_address\";s:0:\"\";s:12:\"places_title\";s:0:\"\";s:6:\"status\";s:1:\"2\";s:11:\"golive_date\";s:0:\"\";s:11:\"golive_time\";s:0:\"\";s:11:\"is_archived\";s:0:\"\";s:10:\"online_url\";s:0:\"\";s:19:\"online_button_label\";s:0:\"\";s:19:\"online_instructions\";s:0:\"\";s:11:\"description\";s:46:\"<p>Marketing Club’s First Event 🎉</p>\";s:3:\"url\";s:0:\"\";s:6:\"source\";s:0:\"\";s:12:\"contact_info\";s:46:\"<p>Marketing Club’s First Event 🎉</p>\";s:9:\"cost_type\";s:0:\"\";s:13:\"cost_donation\";s:0:\"\";s:11:\"cost_amount\";s:0:\"\";s:10:\"cost_other\";s:0:\"\";s:24:\"registration_owner_email\";s:20:\"mischlern@beloit.edu\";s:25:\"registration_instructions\";s:0:\"\";s:32:\"registration_notifications_email\";s:20:\"mischlern@beloit.edu\";s:21:\"registration_response\";s:0:\"\";s:26:\"registration_reminder_text\";s:0:\"\";s:26:\"registration_followup_text\";s:0:\"\";s:18:\"registration_limit\";s:0:\"\";s:23:\"registration_limit_each\";s:0:\"\";s:15:\"wait_list_limit\";s:0:\"\";s:21:\"registration_restrict\";s:0:\"\";s:22:\"registration_open_date\";s:0:\"\";s:22:\"registration_open_time\";s:0:\"\";s:23:\"registration_close_date\";s:0:\"\";s:23:\"registration_close_time\";s:0:\"\";s:10:\"visibility\";s:1:\"1\";s:13:\"external_mode\";s:1:\"1\";}', 'Marketing Club’s First Event 🎉 <p>\n Marketing Club’s First Event 🎉\n</p> <p>\n Marketing Club’s First Event 🎉\n</p> ');) (etc.)

@jwilcox Do you happen to see any of this with your test event?

Thanks,
Nick

@mischlern Sorry, I got my versions wrong. My testing consists of a Google Sheet with notes in it. I looked at the sheet’s revision history to see when I removed the note about emojis causing logout. I did that on July 2, so I cross-referenced that against LW version release dates, and assumed I was testing 2.20.1 at that time. But I forgot to take into account dev servers updating sooner. On July 2, our dev server was actually on 2.20.2, so that is what I was testing. Perhaps that is when a fix occurred? But LW also updated our PHP version around that same timeframe, so I can’t say for sure the version number has anything to do with it.

FWIW, I do not see any errors like what you posted above.

Hi Jon & Nick,

Thanks for letting us know what you all are seeing. We’re checking this out and we’ll let you know what we find out.

Rachael

Hello Rachael,

One parallel issue, potentially related.

I’ve been randomly been forced to log out most of today, sans-emojis.

Checking Debug / Errors, starting around 5 a.m. central time, I’m seeing sets of errors like the following:

Line 149 :05-Sep-2025 11:54:53 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 150 :05-Sep-2025 11:54:53 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 151 :05-Sep-2025 11:54:52 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 152 :05-Sep-2025 11:54:52 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 153 :05-Sep-2025 11:54:52 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 154 :05-Sep-2025 11:54:51 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 155 :05-Sep-2025 11:54:51 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 156 :05-Sep-2025 11:54:51 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971
Line 157 :05-Sep-2025 11:54:50 America/Chicago PHP Warning: session_start(): Failed to initialize storage module: user (path: /var/lib/php/sessions) in /var/www/www.beloit.edu/livewhale/class.livewhale.php on line 971

The number of lines per instance varies: 9 here, but also 7, 2, 9, 2, 23, 8, 6, 15, 4, 1, 3, 1, 3.

I’m not 100% certain that these correlate with me being kicked out like I was with the emojis. That said, I am seeing another mention of session_start(), which leads me to believe its likely related.


Follow-up

Just had another editor encounter this, and experience the longest chain of these errors (15:17:51 → 15:18:16). When they attempted to log in again, they encountered this:

"/livewhale/?login_no_database"

I am praying that the emojis aren’t eating our server bit by bit. :grimacing:


Let me know what more I can do to help.

Thanks,
Nick

Please see the follow-up appended to the previous post. Seems like something odd is happening with our database?

I just had another instance occur to me. Here’s the sequence I experienced while logged in and working.

1. I refreshed a front end page. It loaded without widgets or the toolbar.

2. I switched tabs to another loaded page. I got the “you’ve been logged out” prompt.

3. I logged back in. Checking debug, three new session_start() messages at the same time I was logged out.


I’m still not certain if its related to the initial issue, but my guess is that my attempts to work with and test the emoji-events yesterday got “baked into the database” somehow. Like that activity existed yesterday, but was formally recorded overnight. Given the timing, maybe something to do with the core_daily process?

If these are related, I’m not finding this as amusing as I first thought. :upside_down_face:

Thanks,
Nick

Hi Nick,

Thanks for the information—we’ve been able to reproduce this behavior when testing on our installations and we’re investigating the behavior. We’ll keep this thread updated on what we find out and apologies for any inconvenience in the meantime.

Thanks,
Rachael

1 Like

Hi Nick,

Sorry to hear this has been giving you trouble. I think we know where the problem is –

  • We’ve long supported a number of emoji via UTF8 character encoding, but as more and more emoji have been added, some of those have fallen outside of that UTF8 encoding can cover.
  • Part of LiveWhale 3.0 upgrades will involve an update to the LW database to use utf8mb4 encoding, an upgrade to the utf8 encoding we had been using for most sites.
  • Session data (including, say, form values when editing the Add a News Story page) gets encoded and saved to the LW database in livewhale_sessions, and when that data gets serialized to save to the db but then unserialized, there can be a data error with some of these emoji, as you’ve encountered. (This could explain why some extended emoji may be able to save to the database in a normal text field, but started mucking up login sessions, since it seems to uniquely affect data serialization.)

So, all that to say – once you’re no longer editing that story, logging out and logging in (or trying a fresh window) to get a new LW session, everything should be back to normal. But, if you’re still seeing problems, feel free to submit a Help Request and we can investigate performing some of the utf8mb4 charset upgrade in advance of LW3 to help alleviate some of the issues you’re encountering.

Karl

Hello Karl,

I believe I understand the general issue, but you appear to be suggesting that it is something temporary that should go away with the current session (login, browser, etc).

So, all that to say – once you’re no longer editing that story, logging out and logging in (or trying a fresh window) to get a new LW session, everything should be back to normal.

In practice, the issue I’m seeing appears to be persistent, almost server-side. I’ve been logged out with this error multiple times since Sept. 5, without working directly with any emojis or new characters as far as I know. Yesterday, I had it happen twice, despite my work laptop being off overnight, browser restarted, fresh login. The first time happened within 2-3 pages of my first login, before I could do anything.

I’m also seeing it happen overnight, presumably when no one is online and making edits. (Server processes maybe?)

To me, it feels like whatever is temporarily breaking or making the ‘user’ entity unavailable is cooked into something somewhere. I don’t know the specifics to take a good guess, but some speculations on possibilities:

  • The emoji was in the event title. Perhaps an activity record like "Nick edited Marketing Club’s First Event :tada:” is somewhere, occasionally attempted to be read, and breaks.

  • If not the emoji itself, perhaps other errors were written back. Operation A reads an emoji, the result is good enough for one operation, so it does what it needs to writes it back. Operation B attempts to read this data, either doesn’t like the initial or what A did to it, so breaks.

  • Maybe something on the user’s side, like a cookie or similar. That seems unlikely though, given another editor encountered this same issue seemingly at random, without any obvious work with emojis.

Thanks,
Nick

Thanks Nick – that does seem strange that the issue is persisting like that across login sessions.

At this point, I think we’ve reached the limit of what we can troubleshoot abstractly here in the Forum. To continue investigating, please submit a request through the Help Request Form. That will give us the ability to log in and work directly with your server to diagnose the problem. We can also try out different fixes and have you re-test.

Will do. Thanks, Karl.