Joplin 1.0.201 (prod, darwin)
Client ID: c49067c17dd94e6dab4bf2f4a702df21
Sync Version: 1
Profile Version: 28
Revision: e65af8c (master)
When I choose to export a notebook using HTML Directory, two folder are created: A folder named after the notebook, and a _resources folder. The notebook-named folder contains a sub-folder called pluginAssets. It would be nice if all folders were contained in the notebook-named folder.
Could this be done ?
Hi,
Just a user not a dev.
I was thinking that it may help the devs decide if they could spare time to do this if you gave an idea as to what benefit this would give or which use-case this would support?
Because if you export multiple notebooks at one time, they are all needing to be next to each other in directory structure forever more. If the directories are kept separate, the directories can easily be moved around, and it’s easy to know what belongs to what notebook.
And just organizationally, I’m not sure what the benefit is to create multiple directories rather than one root dir.
Wow it’s incredible they don’t even try to fix this. Maybe it’s not that easy because when you export, new notes with new IDs indeed have to be created, which means existing links are now invalid. Joplin handles that by parsing the notes and changing the old IDs to the new ones so that they remain valid. The code to do that is not that simple, but certainly not beyond the means of a multi-millions dollars company.
But I guess fixing the export format is very low priority for them. Given the choice they’ll probably even provide no export format at all so as to vendor lock their users further.
Each note has a GUID (global unique identifier). This can be used in the ENEX format to identify the note. If the note references another note, it would do so by the GUID. This GUID wouldn't need to change and is perfect to use. IF the note is reimported, the GUID can be re-used since it's always guaranteed to be unique.
Offering export and import seems dumb since there will be broken imports. I don't see why it would be low priority, but companies do dumb stuff.
Because it's not in their interest to make export easy and clean. They don't want you to leave their ecosystem. Mind you, lock-in is generally a terrible retention strategy to rely upon, so maybe they have another reason, but it certainly effects their prioritization.
I just realized I posted that screenshot in the wrong thread 
It should have been here.
Anyway. Back to topic here 
Is it reasonable to have the folders contained ?
No, the GUID has to be changed when you export, otherwise if you re-import you can end up with two notes with the same GUID. Or the apps could change the GUID when importing, but then it unnecessarily complicates the job of apps that need to import the format. It's best to ensure that the exported note is truly unique from the start.
The way I would deal with that is if there's already a note with the same GUID in the database is I would prompt the user about which note to keep, saying it's already in the notes. It's not a problem at all.
There are references to note IDs a bit everywhere, in the sync state, tags, links between notes and resources, etc. Not to mention IDs that might be referenced by third-party apps that access notes via the API. A user cannot make an informed choice here.
But also, what if I export all my 4000 notes as a backup, then a few weeks later I realise I want to restore some of them? Currently, all I have to do is import the JEX file, then copy the notes and it's done. With duplicate GUID, I'll have to decide whether I need to keep or replace each of the 4000 notes, which of course is not practical.
What's the problem with other API's accessing the notes ? You mean if it's been modified downstream somewhere and not saved and they're out of sync ?
A "Yes to all" button is pretty easy to do 
If you simply import all with new GUID, you'd have to go through all 4,000 manually and figure out what changed. That's not practical either. If you're dealing with that kind of import, there's not going to be a good solution regardless.
This thread got a bit off-topic since I posted something here by accident. Is it possible to confine everything to a single directory for the HTML export? I'll happily donate a bit more 
