No major new features so far but various improvements and bug fixes to improve stability, performance and usability. Thanks to everyone who helped with this release!
Edit: actually the support for multiple profiles is a relatively big deal, since it's been asked many times but it's a bit experimental at this point.
Loving the profile switcher!
A few bits of feedback off the bat:
Do you reckon the profile could have the option for a limited local settings sync if desired - obviously not sync target but things like the keymap, css and various settings like appearance, markdown plugins etc.? The first two (keymap and CSS) could just be "hard linked" but the other settings would need to be more selective.
Just had a play with the Windows portable app and when it created the new profile in JoplinProfile\profile-tf8pcue7 it doesn't auto-generate any blank css files like you get with the main app. It does generate them when you open the file through the appearance UI though.
There only seem to be 3 commands for switching profiles hard coded to 1, 2, 3. I don't suppose there could be a command that lists or prompts for a profile with a popup after the command is executed to assist if there are >3 profiles?
Thanks!
Most of the settings are shared between - things like locale, appearance, editor preferences, etc. That also includes the paths to the custom CSS files I believe. The keymap however is not shared but probably should be so I'll add that.
Plugins are trickier because they often have settings specific to the current profile (for example if they store a notebook ID) so currently each profile has its own plugins and plugin settings.
That would require some additional UI work so I'm not sure. If we find there's a need for more than 3 profile commands, we can always add more but I'm guessing most people will have at most 2 profiles, just Pro and Personal.
I just realised that annoyingly, I was messing around the the profiles and got mixed up with what was set as appearance width (which seems to default to 0 rather than 600 now?).
The CSS files definitely aren't being shared though (at least on the portable app). Changes to userchrome aren't showing up on the second profile and opening the .css file through the UI generates it in the child profile folder.
i.e.
I think what would be good is if there are no .css files in the root of the child profile then it links to the master profile but presence of the files in the child profile should override the master files (including blank css files to force the default appearance).
For plugins I guess it makes sense if the plugins themselves are installed just not the settings copied (I've not played with the plugins in a child profile yet).
I agree, just preempting the inevitable "I require 214 different profiles and I can't possibly use this application without this functionality".
which seems to default to 0 rather than 600 now?
Yes it does. I thought we needed a break from the questions "why is there a margin on the side of each note?" 
The CSS files definitely aren't being shared though (at least on the portable app). Changes to userchrome aren't showing up on the second profile and opening the .css file through the UI generates it in the child profile folder.
I think the property itself is shared but there's probably something hard coded to the current profile that's causing problem. If per-profile CSS is ever needed, we could add a class name at the root like "profile-xxxx" and it will be possible to target one or the other profile with this.
They can have 214 profiles, but it's the shortcuts (either from the command palette or keyboard) that would be missing. But it wouldn't be hard to add switchProfile3, switchProfile4, etc. till 9 for example, which would enable the keyboard shortcuts and palette commands
I also note that you can provide different paths to the profiles.json so you can have different profiles on different areas of the filesystem (or off of the local filesystem entirely) - is that a feature or will it be an undocumented/unsupported one?
Currently it can only be a relative paths, and I don't think any special paths, such as with "..", will be properly supported (although it might work).
It works with an absolute path as far as I can see, I put it on a different (hard) drive I have mounted to my file system:
/media/dae/mint-hdd/profile-5imhxn9k
A regression bug, the response returned by delete /resources/:id is no longer json, the expected response type returned is json, and using await (await fetch()).json() will result in failure
curl -X DELETE 'http://localhost:27583/resources/c9141e1f890140f8895ddebea3b87458?port=27583&token='
When I get a note that doesn't exist
$ curl 'http://localhost:27583/notes/test?port=27583&token=5bcfa49330788dd68efea27a0a133d2df24df68c3fd78731eaa9914ef34811a34a782233025ed8a651677ec303de6a04e54b57a27d48898ff043fd812d8e0b31'
{"error":"Not Found: \n\nError: Not Found\n at C:\\Users\\rxliuli\\AppData\\Local\\Temp\\27mc5Z3ZGB8Qnx1bjkXSjEO5ux8\\resources\\app.asar\\node_modules\\@joplin\\lib\\services\\rest\\utils\\defaultAction.js:27:23\n at Generator.next (<anonymous>)\n at fulfilled (C:\\Users\\rxliuli\\AppData\\Local\\Temp\\27mc5Z3ZGB8Qnx1bjkXSjEO5ux8\\resources\\app.asar\\node_modules\\@joplin\\lib\\services\\rest\\utils\\defaultAction.js:5:58)\n at processTicksAndRejections (internal/process/task_queues.js:95:5)"}
DELETE calls normally don't return anything? Why do you need to read the response?
Sorry, two problems caused by my change to the base request library axios => fetch
responseType=json is setresp.status instead of throwing an exception directly, so I need to handle it manuallyAutomatically start sync after setting the sync parameters
What does this mean? Will we still have enough time to set the sync target, and then expand the advanced settings and set things like the fail safe, re-upload local data, etc?
Yes, it's when saving the settings that it synchronises.
Hi Relate to switching profile; This is a useful feature to set of notes under 2 or more different profile. But in my case I found that switching from one profile to another I lost the Joplin application layout, specially when switching from a main Joplin profile that was set up with a particular layout. I do not know if this is related to userchrome.css file or not but, Is there any way to save and keep the Joplin layout after switching between profiles?
Thank you for another brilliant update! I noticed that regarding the attachments in the Viewer, Context Menu commands like "Save as", "Reveal file in folder", "Copy path to clipboard" and "Copy image" don't work anymore. Tested with different attachment types (images, pdf, docx, xlsx, 7z etc), and also with a clean profile (no plugins installed) with both installer and portable app (Windows platform). Furthermore, there are no errors in the logs. Let me know if you need anything else.
So just to be clear, nothing needs to be fixed on api side, is that correct?
yes
Yes that's indeed a bug, this PR broke the context menu - https://github.com/laurent22/joplin/pull/6126 but hopefully that shouldn't be too difficult to fix.
A new release is available: Release v2.8.3 · laurent22/joplin · GitHub
In this one I've enabled again the plugin throttling logic, because we are having quite a few problems with Joplin freezing and taking 100% CPU due to faulty plugins.
I've tweaked it and tested with several of the plugins that were mentioned last time (in particular Note Link System, Note Overview, Note Tab, Quick Link) and none of them will be affected by the throttling. The two that are broken by these release are:
Because of a bug, both these plugins can make an infinite number of simultaneous requests (until Joplin and/or the computer crashes). So now the plugin system will no longer respond to API requests once 100 simultaneous requests is reached.
If you notice any plugin that no longer works please post here.