Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neo Block Loses Hierarchy when entry is trashed and then restored #840

Open
brianrivet-tilt opened this issue Feb 1, 2024 · 8 comments
Open

Comments

@brianrivet-tilt
Copy link

Bug Description

I have a site where a user deleted a page by mistake. The page uses a Neo field for its page builder. When the page was restored, all of the Neo blocks lose their hierarchy and get put at the top level, with some of the nested blocks even disappearing entirely.

I have a backup of the database with the pages intact, but every time I attempt to restore the backup, the content loses hierarchy again with the same blocks going missing.

If need be, I can provide the backups of each for comparison.

Steps to reproduce

  1. Create a page with Neo blocks.
  2. Delete the page
  3. Restore it

Expected behaviour

The pages should not be losing their content hierarchy nor should they lose blocks, but should be restored entirely. In any case, a restore of the database backup should be rendering the data correctly and it isn't.

Neo version

3.8.6

Craft CMS version

4.5.5

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

@brianrivet-tilt
Copy link
Author

Correction, there are no missing blocks, but all of the blocks are in the field at the top level regardless of whether they are supposed to be able to be there or not.

@ttempleton
Copy link
Contributor

This was fixed in 3.9.0 (749e6c1). Unfortunately the bug took effect when the entry was trashed, so the block hierarchy would need to be recreated at that point.

@brianrivet-tilt
Copy link
Author

Thanks. We may need to revisit this. I updated Craft and Neo to 4.7.1 and 4.0.3 respectively on my local (the DB on my local was from a backup done before the entries were deleted, so the Neo blocks were intact). I then pushed the updates to the production site and then replaced the DB with a backup from my local. I would have expected that the entries would have returned to normal and been intact as they are on my local copy of the site, but when I view the entries in question after the backup restore they still show no content. I'm going to recreate the blocks manually because I need to get this resolved, but I don't know that the problem is entirely fixed.

@ttempleton
Copy link
Contributor

If possible, could you please send that database backup and your composer files to plugins@spicyweb.com.au and let us know of an entry this is happening with, and we'll have a look.

@ttempleton ttempleton reopened this Feb 5, 2024
@brianrivet-tilt
Copy link
Author

I've sent the files you requested. Let me know if you do not receive them or if you need anything else from me. Thanks!

@ttempleton
Copy link
Contributor

Thanks for sending that. When starting from before the entries were deleted, deleting and then restoring them works as expected for me.

I might have misread your previous comment though; when you restored the database to the production environment, the Neo fields on those entries were broken in that environment without having deleted and restored them, but the fields were all intact with the same database content on your local environment? If so, I'm wondering if there was some weird caching issue going on.

@brianrivet-tilt
Copy link
Author

No problem. Let me recap because what you got from the comment was incorrect. I restored the 4.5.5 database to the server before running the upgrades. The posts are intact there and there was no problem with them, but then after running the upgrade they showed up as damaged again. I don't know if the damage happens when the database is restored or what, but my local copy of the site (4.5.50 showed no damage so that was where I pulled the backup from that I used to do the restore.

@ttempleton
Copy link
Contributor

Ah, okay, those were the steps that I took with your database. I'm not really sure why it worked fine for me and not you, maybe there's an environmental issue of some kind. I'll keep this issue open for a while in case it happens again with another entry or if anyone else has the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants