Notepad++ 7.6 & new Plugins Admin

[Zanzaraaa]

@donho said:

@Zanzaraaa said:
OK, I see. How about an empty file pluginsForAllUser.xml makes Notepad++ load from %ALLUSERSPROFILE% ?

Yes that sounds good. Also pnedevs idea is good. it should be possible to define if you want plugins to be loaded from both paths or only one.
But why use %ALLUSERSPROFILE% and not keep the plugins folder in the program files install folder like in pre 5.7 versions?
Also i’m still concerned about migration of existing plugins. i wonder if it is possible to keep things like they were in pre 5.7. that you dont have to migration plugins from the plugin folder into their own subfolder.

So I will provide a simpler way for the deployment of Notepad++ - could you test to see if it’s suitable for companies?

Sure, i can test it.

[NoMoreFood]

@donho said:

@Andrew-Briggs said:

I confirm as well. Notepad++ needs to use folder names based on architecture e.g. %USERPROFILE%\AppData\Local\Notepad++\x64\ and %USERPROFILE%\AppData\Local\Notepad++\x86 etc or some other structure that has unique folders for the 2 x64 and x86 architectures.

Please give me a reason that we need that.

This was not my comment, but I agree with it. Since DLLs can only be loaded by a version of Notepad++ compiled for the same architecture, it makes sense to design it such it can safely execute the 32-bit version and a 64-bit version side-by-side on the same machine.

[NoMoreFood]

@dinkumoil said:

@donho said:

Which folder is suitable for this enhancement?

As @SinghRajenM already suggested here:

%allusersprofile% … or can it be kept in %programfiles% itself

Use of the Notepad++ execution directory may also make Notepad++ running in portable mode more plugin friendly since it will all be self-contained.

[donho]

@pnedev said:

There is also the case when some plugins are needed by ALL users using the computer and some are for personal use.
Best would be to be able to install and load plugins from %ALLUSERSPROFILE% as well as from %LOCALAPPDATA%.

The idea is good, but there’ll be some situation which make Plugins Admin behaviour inconsistent:
If the same plugin foo.dll is in 2 different location, %ALLUSERSPROFILE%\Notepad++\plugins\foo\foo.dll and %LOCALAPPDATA%\Notepad++\plugins\foo\foo.dll
Notepad++ will load only one (old behaviour). If user removes one of 2, the remain one will be loaded by Notepad++ - user will be confused.

So the best behaviour (to me) is loading plugins only from one location.

[donho]

@NoMoreFood said:

@dinkumoil said:

@donho said:

Which folder is suitable for this enhancement?

As @SinghRajenM already suggested here:

%allusersprofile% … or can it be kept in %programfiles% itself

Use of the Notepad++ execution directory may also make Notepad++ running in portable mode more plugin friendly since it will all be self-contained.

Indeed, it’s the current behaviour - if Notepad++ is not installed in Program Files.

[pnedev]

@NoMoreFood said:

it makes sense to design it such it can safely execute the 32-bit version and a 64-bit version side-by-side on the same machine.

Why, what is the justification behind that?
Just curious.

[pnedev]

@donho said:

If user removes one of 2, the remain one will be loaded by Notepad++ - user will be confused.

Hm, not sure about that, maybe you are right.

I kind-of lost the reason behind the idea of moving all plugins out of Notepad++'s install folder. Keeping all plugin’s files under a separate sub-folder in plugins is nice but why in user’s personal folder?

[dinkumoil]

@donho said:

@Andrew-Briggs said:

I confirm as well. Notepad++ needs to use folder names based on architecture e.g. %USERPROFILE%\AppData\Local\Notepad++\x64\ and %USERPROFILE%\AppData\Local\Notepad++\x86 etc or some other structure that has unique folders for the 2 x64 and x86 architectures.

Please give me a reason that we need that.

To support the supporters here in the forum it would be a nice gesture. They will have a lot of work in the next time with users who appear here in the forum and the issue tracker because they are running into problems after updating to Npp v7.6. If you look around you can see it already.

[SinghRajenM]

@donho

@donho said:

@pnedev said:

There is also the case when some plugins are needed by ALL users using the computer and some are for personal use.
Best would be to be able to install and load plugins from %ALLUSERSPROFILE% as well as from %LOCALAPPDATA%.

The idea is good, but there’ll be some situation which make Plugins Admin behaviour inconsistent:
If the same plugin foo.dll is in 2 different location, %ALLUSERSPROFILE%\Notepad++\plugins\foo\foo.dll and %LOCALAPPDATA%\Notepad++\plugins\foo\foo.dll
Notepad++ will load only one (old behaviour). If user removes one of 2, the remain one will be loaded by Notepad++ - user will be confused.

So the best behaviour (to me) is loading plugins only from one location.

IMHO, loading from both places should be considered. Reason is below -
In companies (at least in mine), we have a shared PC loaded with lot of licensed software (providing individual license is costly). And we access that PC regularly for multiple purposes e.g. remote connections, RCA using licensed software etc.

Now,

1. my colleague is found of “xmltool plugin” while I’m not. I am found of DSpellChecker while my colleague is found of some other. So Default plugins (shipped with N++) can go to programfiles which allows only admin to alter it while user specific can go to %appdata%. Also preference should be given to user specific plugin as user intentionally puts it in %appdata% and s/he knows what s/he is doing.

2. Also, the update of existing plugin should to %appdata% which will be always loaded as preference is given to user specific. Reason is: 1. user A is happy with version 1.1.1.1 while user B always prefer latest version. 2. Standard user can’t write to programfiles.

3. Offcource, new installation should go to %appdata% as only user A wants that plugin while user B does not.

I hope this makes sense. Thank you.

[Jürgen Ernst Günther]

Same 7.6 but Win10 (64-bit)

I even gave “C:\Program Files\Notepad++” as a whole to me and reinstalled.

I cannot install any new plugins using the admin. It works some magic in background and reappears just as before.

Plus: Even pre-installed plugins vanish as soon as I try to update them.

But it looks nice. Is there a (future) possibility to install plugins for all users? 🧐

[Fran Favorini]

@donho said:

@Zanzaraaa said:

but in company environment where you have some plugins that you want or have to provide to ALL users, you just had to copy the plugins into the program files plugin folder and every user has it when he starts notepad++. no need for users to manually mess around.

OK, I see. How about an empty file pluginsForAllUser.xml makes Notepad++ load from %ALLUSERSPROFILE% ?

also normally i delete the plugin manager after installation because we dont want users to use it to manually install or update plugins. they should only use the ones we provide.

So I will provide a simpler way for the deployment of Notepad++ - could you test to see if it’s suitable for companies?

I like the new structure of each plugin in its own subdirectory, but like Zanzaraaa, I have to manage hundreds of computers in an organization, and we cannot allow users to run executables from insecure directories like %LOCALAPPDATA% (or %APPDATA% or %TEMP%). Those directories have “Data” in the name for a reason. They are for data, not executables. The same is true for %ALLUSERSPROFILE% (aka %PROGRAMDATA%), but that would be an OK workaround if there is not a way to put the plugins under Notepad++‘s Program Files directory (not sure why this is the case). At least in the latter case, we know there is one and only one location where plugins will be, and we can lock down the permissions. Note, we still want users’ settings to be stored in %APPDATA% (or registry) so their profiles can roam from machine to machine.

I am happy to help test this, if you need it. Thanks for providing a great, free editor and for all your hard work.

P.S. I think separate x64 and x86 plugin subdirectories would be wise, but not a big deal for us.

P.P.S. In addition to the “Stable” field in the Plugins Admin list, it would be nice to have Download Count or even a User Rating, so we could get an idea of a plugin’s popularity (and to some extent, quality/safety).

[NoMoreFood]

@pnedev said:

@NoMoreFood said:

it makes sense to design it such it can safely execute the 32-bit version and a 64-bit version side-by-side on the same machine.

Why, what is the justification behind that?
Just curious.

Why would you want to run two versions side-by-side? Mainly if you have plugins or other code that isn’t compiled for 64-bit / 32-bit. For somewhat similar reasons, it’s why we have ‘Program Files’ and ‘Program Files (x86)’.

[AJ-Stevens]

Typically for programs with plugins on Windows, you’d see an option to allow per-user plugins at install (as install requires administrator rights) or within the application settings in a system section (which is stored under Local Machine registry or Program Files and hence require admin to change) as apposed to most application settings which are individual user preferences and stored in Current User Registry (or users %AppData%).

The application would load Plugins first from Program Files installation, and IF user plugins have been permitted then load in plugins from the users %AppData%, the user ones would overwrite or be used instead of the system installed plugins.

If user plugins are allowed, when users install plugins they go to their %AppData%, if user plugins are not allowed, then they’ll be stored under Program Files, in this instance, we still need the Plugins menu to be visible for users so they can see any plugins that have been loaded in by Administrators, and allow users to access Plugins Admin to install, update and remove plugins, initially a user would only be able to see Available, Updates and Installed Plugins, to be able to change (install/update/remove), they would have to click a “Change” button (typically has a UAC symbol) to present a UAC credential request, which then runs (relaunches?) Plugin Admin with Admin credentials so only Administrators can make plugins changes, once done and closed return to Notepad++ which is still running as a normal user context, with a prompt to restart as there have been changes to plugins.

%PROGRAMDATA% (or old school %ALLUSERSPROFILE%) is the location for shared data for an application and all users to be able to write to. It’s possible you could use this to store Plugins in for all users as a single plugin location, if you or your company don’t require the security of admin access to add a plugin, which in this day seems less likely.
What’s to stop user A on a PC loading in a malicious plugin to Notepadd++ that UserB doesn’t know is there when they next run Notepad++ on that same system?

At the moment, I have to run Notepad++ 7.6 as Administrator to use or add plugins which is not ideal, prefer to be in a user context, hope this gets corrected soon.

Thanks for the great software by the way.

Additional:

@NoMoreFood said:

@pnedev said:

@NoMoreFood said:

it makes sense to design it such it can safely execute the 32-bit version and a 64-bit version side-by-side on the same machine.

Why, what is the justification behind that?
Just curious.

Why would you want to run two versions side-by-side? Mainly if you have plugins or other code that isn’t compiled for 64-bit / 32-bit. For somewhat similar reasons, it’s why we have ‘Program Files’ and ‘Program Files (x86)’.

If I were to need to run both 32bit and 64bit, I’d say 32bit would be the default, but at times may require 64bit, say a particularly large log file perhaps? Not sure if it needs separate directories or if the plugin makes just have “64” in the plugin filename for the 64bit dll.

[dinkumoil]

@AJ-Stevens

The reason why plugins are no longer installed to %ProgramFiles% is according to this comment of @donho the following:

The reason of installation to <Userprofile>\AppData\Local\Notepad++\plugins<plugin-name> is Microsoft’s Universal Windows Platform. A UWP package is immutable so there’s no way to install plugins into Notepad++ installation directory.

It seems like he wants to publish its own Windows Store App variant of Notepad++, thus there is no way back to installing plugins (even partially) to %ProgramFiles%.

[pnedev]

@dinkumoil said:

The reason why plugins are no longer installed to %ProgramFiles% is…

Thanks for explaining that, it seems I’ve missed (or forgotten) Don’s post.

[Fran Favorini]

@dinkumoil said:

@AJ-Stevens

The reason why plugins are no longer installed to %ProgramFiles% is according to this comment of @donho the following:

The reason of installation to <Userprofile>\AppData\Local\Notepad++\plugins<plugin-name> is Microsoft’s Universal Windows Platform. A UWP package is immutable so there’s no way to install plugins into Notepad++ installation directory.

It seems like he wants to publish its own Windows Store App variant of Notepad++, thus there is no way back to installing plugins (even partially) to %ProgramFiles%.

I would suggest if Notepad++ can write to %ProgramFiles%, it should. If not, fall back to %ProgramData% or %LocalAppData%, as configured. If there’s ever an issue with loading plugins from multiple places, it should pick the first one it finds in %ProgramFiles%, %ProgramData%, or %LocalAppData%, in that order. User versions of plugins should no be able to replace admin-specified versions.

[László Botka]

Hi @donho ,

Unfortunately here the plugins subfolder in the install folder contains in addition to the disabled subfolder the Images subfolder for the Bookmarkmanager. So if the plugins subfolder is removed in a new version, I have to recreate it copying the bookmark manager marker images - presumably the plugin needs to be modified.
I do not know if there is any other solution now.

[donho]

@László-Botka said:

Hi @donho ,

Unfortunately here the plugins subfolder in the install folder contains in addition to the disabled subfolder the Images subfolder for the Bookmarkmanager. So if the plugins subfolder is removed in a new version, I have to recreate it copying the bookmark manager marker images - presumably the plugin needs to be modified.
I do not know if there is any other solution now.

Then you have to modify your plugin to adapt the new plugin folder structure. There’s no way back for this point. OTOH, I can promise you that such policy will be remained. So you won’t modify your code all the time.

[Marshal-Kilgore]

@donho
First I’d like to thank you for all the work you’ve put into this great program and your patience with humble user requests.

I’ve thought about the issue and would suggest to make the relevant paths user configurable, including the location of the standard configuration files.
For the current installation of Notepad++ 7.6, this would be:

Config folder: %AppData%\Notepad++
Plugin folder: %LocalAppData%\Notepad++\plugins
Plugin config: %AppData%\Notepad++\plugins\Config

or %ProgramData%\Notepad++\plugins, should you decide to change it.
System administrators and experienced users could tweak these paths to match their backup strategies, security concepts, etc.
A portable installation would simply use:

Config folder: .\
Plugin folder: .\plugins
Plugin config: .\plugins\Config

relative paths being relative to the installation folder, of course.
Developers could have multiple parallel installations of Notepad++ in 32bit and 64bit, using custom folders like:

Config folder: %AppData%\Notepad++-32bit-testing
Plugin folder: %LocalAppData%\Notepad++-32bit-testing\plugins
Plugin config: %AppData%\Notepad++-32bit-testing\plugins\Config

or

Config folder: %SCRATCH%\Notepad++-64bit-beta
Plugin folder: %SCRATCH%\Notepad++-64bit-beta\plugins
Plugin config: %SCRATCH%\Notepad++-64bit-beta\plugins\Config

The effort would be an extra configuration file (that resides in the installation folder) and should satisfy most grumblers. >;-)

[ManiacJoe]

Windows 10.1709

Notepad++ 7.6, 64-bit, build 2018-11-13 00:12:05

Admin plug-in dialog, update tab:
three items listed
select one or more
click update button
It tries to download Notepad++ 7.5.9 when it should be downloading new plug-ins.