I’ve been inquiring with other users, and no one I’ve asked as seen it. Others may have seen it, but no one has yet asked me about it.
While working on another issue, I stumbled on this in the AJAX/JS debug (/livewhale/?lw_debug=9):
09-Jul-2025 1:12:28pm CDT LiveWhale Notice: /live/editor/start_editing/profiles/9158 AJAX error: The returned content does not match the expected format: th[ ]… ( details / url / mischlern )
Our earliest instances appear to be June 25, one day after our most recent update.
This and other instances appear to correlate to instances that occur while working in the backend/dashboard, affecting multiple types. I also see notices triggered by other editors, suggesting that this isn’t just a issue specific to me.
I’m not certain what functionality this error is referring to for the backend. I suspect something fundamental to LiveWhale but not critical to functionality (i.e. list of item’s history for reversion).
I also suspect that the backend issue is related to the issues observed on the front end, given the overlap of “th”. If so, then the cause is likely to be something that affects any and all pages loaded, or the content it is getting is occasionally malformed. Idk.
Thanks for these diagnostic notes, Nick. I haven’t heard of this arising for anyone else (though, please feel free to speak up if so) – we’ll take a look at reproducing this on our end.
Checking with the team, sounds like we sometimes see this once in a blue moon when someone is editing a PHP file and accidentally leaves some bogus text in there (like “th”). We’ve see sometimes like th<?php at the top of a file or some such.
As a debug step, you could try reviewing any custom module code that got edited recently to check for that kind of code typo. Or, if you’re able to find steps to reproduce the error case on dev, you could temporarily disable custom modules by moving them from /modules/ into a folder like /modules_disabled/ or /modules_unused/ to see if the problem persists there. Hope this helps!
That was one of the things I tried when I first noticed the issue. I did make a mistake with a file at the same time and reverted, but it didn’t appear to be related. I also did a quick look for “th” at the head of files at the time, didn’t see anything obvious.
A thought: if it is a typo in a custom module, and assuming I understand the situation, why would the issue appear on both the backend (private) and frontend (public) of the site? Wouldn’t that require an identical typo in two separate files?
That said, I just did a thorough review of the custom modules, and I didn’t find anything obvious. I tried to do a regex approach – th[^A-Za-z] – to also look through the entire file in case it was within a conditional. The appearance of the issue doesn’t seem to match any clear conditional behavior in our modules (i.e. if ‘profiles_edit’ then).
The closest thing I found in my search were two public modules around COVID statistics that involved making tables, or table structures in XML. Lines like:
I’ve moved these both to a modules.archived folder, in case they were being called unnecessarily and causing issues. I have a feeling these weren’t the cause, though.
I’ll keep an eye out to see if anything has changed.
A global module would be used in the front-end and back-end, if that’s useful context. Sounds like you’ve already considered that case, but for anybody else encountering a similar issue.
Keep us posted on how it goes, and we’ll stay tuned for any other examples—we’ll see if we’re able to reproduce your current logged examples in the meantime.
I was able to encounter this on the backend of the site. It appears that the issue causes this error message to appear on the screen: “Whoops, there was an error communicating with the server! Please check your internet connection and try again.”
I’m not certain, but I think this error occurred asynchronously. I left the profile editor open to talk to someone, then came back to see the “Whoops” error.
This got me thinking: I saw once instance of a user triggering the error multiple times on a single page. From what it appears, this editor opened an event edit page in the morning and left the tab open all day, leading to this:
I’ve left a bunch of tabs open to try and “farm” the error, and I was able to trigger it. Like the initial error today: the editor page loaded fine, then had the error occured minutes later.
I’m not sure what the backend page would be trying to do every 20 minutes or so, but it seems related to whatever that may be.
Thanks Nick – the backend “who is editing this item” script does ping the server every 30sec at that /live/editor/start_editing/{data_type}/{id} endpoint, so that behavior is expected.
The malformed response is interesting – the endpoint is meant to just return an empty json [] or a json warning ['error'=>'<div class="editing-sessions"><strong>Someone else may be editing this '.$term.'.</strong> It\'s been opened in the last few minutes by '.$editors.'...etc...
The endpoint does load the general LW nocache script, though, which I think leaves us in the same spot which is an intermittent bug, error, and/or typo some place not yet located that is affecting something like the onLoad or onOutput action—something that’s popping up places it’s not meant to.
One thought: if you log into dev and leave an editor open there, does the same intermittent bug appear there? Or is it only on prod?
For what it’s worth, I’ve left a profile editor logged-in on one of our test sites and the /live/editor/start_editing/profiles/## AJAX has fired >100 times, always showing the correct [] results. Hard to prove a negative, of course, but I haven’t seen any reproducing of this bug yet.
For our dev site, I’ve seen it occur on the frontend. I’ve been working to integrate a new search solution, and I’ve seen it appear on refreshes as I work on styling.
Testing the backend, I’m not seeing any sign that it happened. I’ve have ~30 tabs open with profile edit pages for about an hour, “farming” like I did on prod, and it hasn’t triggered. (To your point, proving negatives…)
This is frustrating, as you can expect. Is it me or the server? Is it us or LiveWhale?
I’m still open to the idea that this is still some errant text in a PHP file somewhere, but it must be a sneaky one. Some questions to help me try and look with more intentionality:
What does the “who is editing this item” script use for modules? public or private?
Given I see it consistently on frontend, does it seem right to assume it’s a public widget?
Any specific handlers should I focus on? (onLoad, onOutput, the “any” kind of handlers?)
Assuming a custom module: what are some possibilities that would cause this issue to appear randomly for nearly any request? (Something like “onOutput” would show every load, or if within a conditional, “just events” or similar, right?)
Assuming the “th” may have been in client code for some time, only manifesting after the upgrade: do any changes from recent versions seem relevant?
Since you’re seeing it on dev, I’d suggest a next step is to temporarily disable all custom modules on dev and then see if you’re able to trigger it on a front-end page of dev. If it goes away with the modules removed, that would put the suspicion back on a client module. If it doesn’t, it seems like it’d have to be something else. If you want to share a dev link here where you’re seeing it appear (I’ve clicked around your dev site a bit and haven’t seen it) we can check it out – we’re able to help with browser-based diagnosis here in the forum, we just can’t login/SFTP in to look at files.
At whatever point you feel you’ve exhausted what you want to – and are able to – test on your own, feel free to submit the Request Help Form which will allow us to go hands-on and log in to your prod and dev sites to help track down the issue. Thanks,
Finally found it at the start of /livewhale/core/config.php/.
Thinking it was client-related, I didn’t try the core folder until I tried a more robust regex search of the entire site. I guess a config file may explain how it was appearing randomly, assuming not every request needs to read the config.
Someone (or something) must have appended it accidentally during our last upgrade. I recall being the one to go in and turn off the editor lockout, so it was likely me.
(That said, unless I was mistaken, I thought I also saw it on dev. Checking dev now, I don’t see it there. Maybe it wasn’t there to begin with, or the automatic upgrade to 2.20.2 remade the config? Who knows; lets just assume I mixed pages up.)
In any case, finally, catharsis after two months trying to chase this down. Thank you again, Karl, for helping work through it.
Wow, good catch indeed! Glad you were able to sort this one out. We’re definitely flagging this for our team to be on the lookout for and keep in mind as a place to check in the future.
Thanks for letting us know the culprit and glad that mystery was solved.
I guess a config file may explain how it was appearing randomly, assuming not every request needs to read the config.