Handling images/attachments? about go-markdown2confluence HOT 8 CLOSED

As it's currently written it'll grab any images referenced. So if you use the markdown ![image](image1.png) syntax it should pick it up.

It won't, however, just include all nearby images as attachments.

from go-markdown2confluence.

Can you tell me the expected file structure where it'll grab the images? I'm happy to push files around to the right place if it'll make this work.

from go-markdown2confluence.

It's relevant to the document. If you include an image using the standard markdown spec markdown2confluence will test to see if that file exists locally. If it does, it will upload it.

So, technically, it can be anywhere on disk it just needs to be included in the markdown itself.

from go-markdown2confluence.

After giving this another shot, I realized that I've been changing my source import files to work around a different limitation, but nothing seems to fix the attachments coming through.

Basically, when you export from the thing I'm using, each markdown file gets a hash at the end (which represents the underlying storage ID from the tool). Each page with attachments or child pages has a folder with the same name and hash, just no file extension.

- Home page 3a74d6cf471740aab98165d3cd8cda1b.md
- Home page 3a74d6cf471740aab98165d3cd8cda1b (folder)
  - page1 [hash].md
  - page1 [hash](folder)
     - image1.png
     - image2.png
     - childpage [hash].md
     - childpage [hash](folder)
       - childpageimage.png
   - page2 [hash].md
   [...] 

If you import it straight from the export dump using the default page name, links are flattened, attachments don't attach, and every page has the hash in the file name and a second title below, which need to be cleaned up manually.

If you import it straight from the export dump using the --use-document-title flag, you get a page from the markdown file, and then a second page (including the hash) from the folder. The folder page contains all the child pages and attachments, but none of the content from the markdown file. Links that aren't flattened are broken, and some images come through, but not others.

If you try to remove the hashes from the source files, like I did, you can get the tool to put the markdown content on the page that also has the child pages, but attachments and links are still dead.

At this point I guess I'm at a dead end.

from go-markdown2confluence.

I think this, as well as #14, are going to require some sort of state management to solve for. With the idea being that as we're creating documents in Confluence we're storing the ID of the page created somewhere. We can then translate relative links to confluence pages by referencing this key/value store.

Thinking through this at the time of sync we'd need to create all the documents and store the IDs, then re-update the ones with nested links. So something like this:

• Upload all documents as it currently does
• On upload, store remote confluence page ID key/value store
• On upload, if a link resolves to relative markdown file, defer to a final fix-links-and-upload step
• Reprocess all deferred files that have links to relative markdown files
• To satisfy #14, delete any Confluence pages that exist in the store, but not on disk.

I haven't started writing it, but am thinking of a simple interface that interacts with a backend key/value store. Maybe start with boltdb?

from go-markdown2confluence.

Looks like @sanscontext is (like me) moving content from Notion to Confluence i recognize those hashes.

For my use-case, at least, this is a one-time process and doesn't necessarily need persistent storage; the entire content tree can be visible to the import tool at startup and all state can live solely within the context of that one run.

Thinking through this at the time of sync we'd need to create all the documents and store the IDs, then re-update the ones with nested links

Yes, this matches my (rough) plan:

• do one sweep simply creating empty pages for each .md file w/ proper nesting etc; remember the resulting confluence URLs
• clean all markdown files to replace existing links w/ just-obtained confluence URLs
• reupload all pages, this time mit content

FWIW I had been planning to do most of this work outside of confluence2markdown, just with scripting loops. I haven't coded golang before but maybe I'll dip my toe in.

from go-markdown2confluence.

Yes, the whole thing could be done in one run without persisting storage but not for all use cases. It makes sense for one-time migrations where you're syncing the whole tree, but less so when you're syncing partial files often. I personally use it to sync modified files every 30 minutes.

I'm sure we could make local storage optional, though. If the first pass doesn't have it, it's still worth doing - definitely encourage you to jump in!

from go-markdown2confluence.