Entry loses all content from Neo field in current and all past revisions

[brianrivet-tilt]

Bug Description

I have a site that has an entry that seems to have lost all content from the Neo field and all of its revisions. We don't know how it happened, there's no record of a user deleting the content, and even if they did, the past revisions should still have it. Other fields in the entry hold their values in all of the revisions, but not the Neo field. I can supply a database backup with the error and one from prior to the error showing up.

Steps to reproduce

1. I'm not sure how to reproduce this as I am not sure how it happened in the first place.

Expected behaviour

The field should not only have the content for the entry in question, but all of the revisions should as well.

Neo version

4.2.2

Craft CMS version

4.9.7

What is the affected Neo field's propagation method?

No response

Does this issue involve templating, and if so, is eager-loading used?

This is not a templating issue

[Christopholus]

We are encountering the exact same issue. After updating to version 4.2.2 - we've lost all of our Neo data on a number of entries, with no way to recover the data except manually replacing it via a historical database.

[ttempleton]

Which version did you upgrade from, and are you able to reliably reproduce the content loss if you redo that upgrade?

[brianrivet-tilt]

I have a database backup from about 3 weeks prior to us discovering the problem that still had the entry content intact. The backup was made prior to an update that included going from 4.1.2 to 4.2.2. I don't know if the issue was triggered by that update or not since no one discovered the problem until 3 weeks later, but if that backup will help, I can provide it as well as one pulled from when we discovered the issue.

[ttempleton]

Thanks - could you please send both of those, and your composer files, to [email protected] with directions to the entry where this happened. Hopefully the blocks are still there but just not being picked up in the block query for some reason.

[brianrivet-tilt]

I've sent a link to get to the files along with the info about the entry. The older of the two files is the one with the entry still intact.

[yumpdevs]

Is there any fix for this yet? We have similar issue (going back to any past revision will cause to lose all content - going back to the current will put the live content back) - The site is upgraded from craft 3 to Craft 4. And this issue has occurred ever since. See my video please and enlighten us as our clients need this to be fixed - our current versions:

Craft 4.11.5
Neo 4.2.12

Cheers

What.we.do.Edited.mp4

[ttempleton]

@yumpdevs Unfortunately I've never been able to reproduce this, including with a test upgrade from Craft 3 to Craft 4 that I've just performed.

If you still have your Craft 3 Composer files and database backup with the revision content intact, and you're able to reliably reproduce the revision content loss when upgrading it to Craft 4, could you please send those Craft 3 files to [email protected] and we'll have a look. Please note that we'll be unable to investigate using the Craft 4 files, since the content is already lost.

[yumpdevs]

Hi @ttempleton , thanks for the reply. Sorry I did not put this into my message, but our content did not get lost during the upgrade they were intact. The video I shared and the problem we encounter is now in Craft 4 with all the past revisions. And because we lose data if we use revision, (after the upgrade), we simply advise our client no to use it until a fix comes along. So we have all content intact after the upgrade , only the revision is not working anymore. Hope this helps. Let me know if I still need to provide any Craft 3 files. Cheers

[ttempleton]

When you save an entry a few times, do the newly-created revisions have any Neo blocks?

If they don't have any Neo blocks, could you please send your Craft 4 Composer files and database backup to [email protected] (and let us know if there's a specific entry we should look at) and we'll have a look.

[yumpdevs]

Hi @ttempleton , Yes, our whole body block(that contains all our blocks) is a Neo block and we have other matrix and all other blocks as children of that body block. So each revision will have that big body block as a Neo block. I have sent you the files, will be grateful if you check them out. Thanks a lot.

[ttempleton]

Thanks for sending that - I do see that the existing revisions have no Neo blocks, but also that newly-created revisions save the revision blocks as expected. I am unfortunately unable to debug this, as the content loss has already occurred; I need to be able to reproduce the actual content loss process.

If you're able to reproduce revision content loss on newly-created revisions, could you please provide extra information on how to do that (feel free to send it via email if you prefer). Alternatively, If you have a database backup from before the revision content loss occurred, could you please send that to us if possible, in case I can figure out how to reproduce it there.

[yumpdevs]

Hi @ttempleton , I sent you an older database where the content was not lost. Thanks

[yumpdevs]

Hi @ttempleton , was the older database helpful. Let me know if you could reproduce our problem or is there something else needed. We are looking for a solution please. Cheers.

[ttempleton]

Thanks for sending that in @yumpdevs. Unfortunately I haven't been able to reproduce the revision content loss.

I'll keep investigating it and let you know if I have any updates on it, but is there any chance that any other external code, e.g. custom modules could touch any Neo content using an event? I'm just thinking that this kind of content loss is similar to what we've seen in the past with users of the Preparse Field plugin (albeit in those cases it's been the live entry losing content, not just the revisions), and it's been suggested (without any confirmation that it worked, unfortunately) that those issues could be resolved by cloning any block queries that your code is working with.

[yumpdevs]

Hi @ttempleton , just wondering if there is any update on fixing the issue we reported. Will there be any new update on The plugin for this? Thanks for your help in advance.

[ttempleton]

@yumpdevs Could you please confirm your answer to the question in my previous comment?

[yumpdevs]

@ttempleton , we don't have any custom code or event to manipulate Neo plugin or content.

[ttempleton]

Thanks for confirming that. I am still yet to reproduce this in yours or any other environment, but I will update here if I have any updates to share in the future.

[yumpdevs]

Thanks @ttempleton , looking forward to it. Cheers.

[boboldehampsink]

Hi, I'm having this issue, seems like the same thing?

Schermopname_2024-10-24_om_09.39.52.mov

[ttempleton]

@boboldehampsink I'm unable to reproduce that - if possible, could you please send your Composer files and database backup to [email protected] and we'll have a look.

[yumpdevs]

Hi @ttempleton , it is similar to our issue, if you could provide a fix, that would be amazing. Thanks @boboldehampsink for reporting your issue which we are having as well. Cheers

[ttempleton]

Thanks for sending that in @boboldehampsink. Unfortunately reverting the entry is working as expected for me. Does the issue persist for you if you temporarily disable your custom modules?

[boboldehampsink]

Thanks for sending that in @boboldehampsink. Unfortunately reverting the entry is working as expected for me. Does the issue persist for you if you temporarily disable your custom modules?

So far I can't reproduce it either... have asked the client for more info. Thanks so far.

[boboldehampsink]

@ttempleton this is when reverting to a revision, then switching to another language.

[yumpdevs]

@ttempleton , is there any update on this please. Our clients are not happy with this and we really are looking for some kind of fix if possible. Please give an update on the status of this. Cheers

[ttempleton]

@boboldehampsink I'm still having trouble reproducing that, unfortunately. If you can reliably reproduce that, could you please post another screen recording if possible showing all steps that lead to the issue occurring? Feel free to send it in to [email protected] if you prefer. There must be something I'm doing wrong to not be able to reproduce it.

[boboldehampsink]

Done

[ttempleton]

Thanks @boboldehampsink - just released 4.2.20 to fix that, but please let me know if any issues persist.

[yumpdevs]

Hi @ttempleton , I also tried your solution but the issue persists. Is there something you can do about it. Do you need anything from us to help solving it. It is an issue for us. thanks

[ttempleton]

@yumpdevs Just to be clear - your revision content loss has reoccurred since the release of 4.2.20?

At this point I remain unable to reproduce it, so if it's happened for you again, any additional steps to reproduce you can provide would be helpful.

[yumpdevs]

Hi @ttempleton , our content loss is still happening. We noticed this since (Craft 4.11.5
Neo 4.2.12) and it still happens after updating Neo to 4.2.20 in the very same way shown in the video of my first message in this thread: #899 (comment)
It happens when we try to change to any past revision in the entry as the video shows. Let us know how can we help to be able to resolve this. Cheers

[ttempleton]

Even revisions created since then have no Neo content? e.g. if you resave an entry twice and go to the most recent revision, that revision has no Neo content?

If no to the above, have there been any cases since your original comment where a revision was created with Neo content and has since lost its content?

[yumpdevs]

Hi @ttempleton, When I make changes to the Neo content and save, then try to access the most recent revision just before the changes, the Neo block appears blank.

[yumpdevs]

Hi @ttempleton - I hope you're doing well. I wanted to follow up regarding the Neo plugin issue. We haven’t received a response to our last message, and we’re still encountering the same issue.

To recap:
When we make changes to the Neo content and save, the most recent revision before the changes shows the Neo blocks as blank.

Could you kindly provide an update or any further guidance on resolving this issue? We’re eager to address this as soon as possible.

Looking forward to your response.

[ttempleton]

@yumpdevs Have you overridden Craft's runQueueAutomatically setting? If you've disabled that setting, Neo should avoid using a queue job to save revision block structure data, but maybe that's making the request take too long? After you save the entry, does the newly created revision's ID appear in any rows in the neoblocks_owners DB table?