After upgrading to Bear 2.0 on the App Store, and opening the new app, quite a few inline images fail to show in notes. Some do, some don’t – even within the same note.
What did you expect to happen:
To see all inline images, and work as usual before upgrading Bear 1.x to Bear 2.0
This is a show stopper. I tried restoring from a backup from yesterday and same problem: some images within notes show, some don’t. Instead of the image, a placeholder shows with a path reference (see screenshot):
e.g. 
What’s the point of making backups if notes do not restore properly? Is it possible to go back to Bear 1.0? I resisted downloading the beta / test flight version until launch day so it could be a stable version.
Paid Bear subscriber and user of bear for the last 6 years.
I’m guessing that the issue might be that those images were indented with tabs in Bear 1? I wonder what happens if you delete the tabs (i.e., so  starts at the beginning of the line)?
If the above resolves the issue, I think this seems to be part of a bigger unfortunate side effect where tabs are no longer allowed for aligning texts. Instead, if a line starts with a tab (or more), it is treated as a code block in Bear 2.
@trix180 I think here this is an unfortunate side effect of migrating notes created in B1 with indentation that are no longer legal in B2.
Since they were allowed in B1, some users have been reporting issues of paragraphs turned into code blocks after upgrading to B2. Pure texts might not be that bad to fix, just onerous if you have a ton of those. But it looks like now indented images from B1 can no longer be rendered, even after removing the leading tabs?
Correct. Removing the indent (leading tabs) from inline images does not restore the preview of the image.
Thousands of notes with interspersed indented images not rendering is tantamount to DATA LOSS and a SOFTWARE REGRESSION.
To say this is an overlook before shipping Bear 2.0 is an understatement!
Going to the backup (.bearbk) and renaming it as a .zip, and then subsequently expanding the file, reveals the textbundle of said notes with the corresponding images in the asset folder. That tells me at least that the images have not been lost.
I expect the Bear Team to the very least least issue a warning saying that any indented images within Bear 1.x notes will NOT be rendered upon upgrade to version 2.x
When the Bear team asked on Twitter if we were ready to take time off work to upgrade to version 2.0, I thought it was a cheeky comment not an actual warning!
I imagine that once the issue is patched, your backup could be restored and the images would show correctly (given they are in the backup). Obviously doesn’t help for right now, but possibly gives some hope if you have a lot of work to do?
@HumbleBear : that is my only hope. That sometime in the near future a point release (e.g. Bear 2.01) can restore the inline indented images once again with minimal fuss.
As it is, the 2.0 Bear with 11,000 notes has entered hibernation – no new notes can be added, or deleted without altering the last backup from version 1.x and irreversibly losing thousands of images within those notes.
If removing the indents is an option for you, you could (in theory) extract the zip file, and use sed or similar to iterate over all the files, and remove indents in the markdown, before re-zipping into the .bearbk file for restoration? Just a thought that might help in the meantime
@HumbleBear: been thinking exactly about that all day, but with 11,000 notes it will take me weeks to go through this process manually.
Worse come to worse, I could dedicate the next few weeks of my life to doing that. What a painful lesson that would be.
At the very least, the cause of the problem has now be narrowed to improper rendering of images due to indented tabs.
[Update: I see what you mean with the use of sed, a text stream editor in linux to batch edit thousands of files at once. Will have to teach myself how to use it]
Oh sorry, what I mean is because of the sheer number of notes, instead of doing it manually, you could likely do it with a short bash script (if you’re comfortable with that sort of thing), provided you have a Mac in your mix? If you’re not comfortable, but do have a Mac, you could provide me with a suitably redacted copy of one of your notes and I would be happy to look at writing a script for you if you like.
Edit
I see your update now; give it a shot - use of for loops, and sed, but I’m happy to assist as well if you like
@HumbleBear: let’s say the sed linux editor is able to remove all the indented tabs before inline images.
How would sed differentiate between a tab before an image and a tab before normal text?
Once all .textbundle files are “correctly” edited with the indented tabs removed , would I just rezip the whole archive, change the extension to .bearbk and restore?
Thank you for your help by the way. You are helping me understand this logically.
So that does depend on how the note is formatted, but what I’m expecting is that we’d see a consistent format like: <one or more tabs>, but I haven’t personally tested this. I would obviously keep an original copy of your backup somewhere also, just in case this messes around with your ability to restore at all.
@HumbleBear: brilliant comments. I will test this right away as a proof of concept.
I have the text soap app (Mac) which is able to substitute indented tabs within long notes (no file batches). Then off to rezip the folder, and restore such backup. Will report.
Made several backups in different media before upgrading to Bear 2.0 just in case something like this happened.
Manually editing the .textbundle file, saving it, reziping it, and changing the extension to .bearbk - > restoring the whole database worked on that specific note. Images now render correctly.
Now, time to work on a script to batch substitute inline tabs on 11,000 notes.
What a drag for an update supposedly so great. My fault for not waiting to click “Update”
sorry about the late reply, we were a bit full in the last two days.
I can confirm this is an issue with the migration to the new CommonMark markup: images/files that end up in a code block (via an indented paragraph for example) don’t display as they’re now marked as code.
Unfortunately, this issue did not come up in any migration during the beta (and we’re talking about 10k migrations) and we didn’t handle that
I’ve added a quick patch to 2.0.1 that should at least prevent the data loss by creating a “Lost and Found” note with all the images/attachments that are marked as stray after the migration.
If anyone needs help in fixing the issue if you’re already migrated, please get in touch with me privately and I’ll help you to get back your images/files.
Last 48 hours, I’ve proceeded via trial and error in order to find the culprit of the disappearing images.
Upgraded to 2.0.1 this morning, but nothing changed. Inline images with a leading tab just before them still don’t render even after removing the preceding tabs. This was working perfectly fine in Bear 1.x
The problem is not recovering the images, the problem is recovering the images within the context (at exactly the right position) within the note. Otherwise they are just a bunch of images divorced from context.
Hopefully the script is relatively straightforward!