New Plugins Home (where Notepad++ will load from)

Meta Chuh

currently we have to answer these following 2 scenarios again and again:

users installed to C:\Program Files ((x86)) with the option “Don’t use %APPDATA%” selected
in this case neither plugins nor plugins admin is visible after the installation

possible solutions:
a - more complicated:
grey out “Don’t use %APPDATA%” if the selected path matches %PROGRAMFILES% or %PROGRAMFILES(X86)%

b - quick and dirty:
remove “Don’t use %APPDATA%” completely from the installer.
so from now on it has to be done manually creating a DoLocalConf.xml and copying all files to the np++ directory

the installer was invoked by users without admin rights, so all plugin and plugins admin will reside inside the %LOCALAPPDATA% and %APPDATA% of the Administrator account they have entered but not within the invokers %LOCALAPPDATA% and %APPDATA%
(as @dinkumoil has posted above)

possible solutions:
a - more complicated:
find a way to get the invokers environment instead of %LOCALAPPDATA% and %APPDATA%
it “could” be done a bit complicated by making a 2 stage installer, first has as invoker rights in it’s manifest and writes the invokers environment paths to a common temp location, then the first stage calls the elevated real installer which reads the invokers path from there instead of the installers environment

b - quick(er):
always install to a common environment path like %PROGRAMDATA% as default
and additionally make an installer option to use %LOCALAPPDATA%/%APPDATA% instead for people who might want it or if they want keep it as it is now

what are your thoughts and ideas about this ?

donho

@dinkumoil

I would like to suggest that installing plugins for all users, i.e. installing them to %ProgramData%, should be the standard case in future Notepad++ versions. This would prevent a lot of similar support requests.

Let’s say we let Notepad++ install plugins into: %PROGRAMDATA%\Notepad++\plugins\ by default.
If the described issue is just a small part of use case, then there might be a lot of users (up to 70% maybe?) will be bothered by UAC for updating, installing or removing plugins.

It’s shame to make this feature harder to use, don’t you think so?

dinkumoil

@donho said:

It’s shame to make this feature harder to use, don’t you think so?

Users are used to confirm UAC dialogs when installing plugins from the old Plugin Manager and confirming is only one mouse click, not that hard. If the design of GUP.exe is appropriate (I don’t know if it currently is or not) one UAC confirmation could be sufficient to install a bunch of plugins at once.

In turn, installing Notepad++ and having hassle with the plugin management system is really bad. Apart from that the related support questions here in the forum will never stop and if they are ignored (because they are annoying) users will be upset. You can see this effect already (“Why are these questions ignored?” and so on). Please note: Users usually don’t search the forum for similar topics before posting their questions.

donho

@dinkumoil said:

Users are used to confirm UAC dialogs when installing plugins from the old Plugin Manager and confirming is only one mouse click, not that hard. If the design of GUP.exe is appropriate (I don’t know if it currently is or not) one UAC confirmation could be sufficient to install a bunch of plugins at once.

In this case, %LOCALAPPDATA%\Notepad++\plugins\ is not needed anymore.

dinkumoil

@donho said:

In this case, %LOCALAPPDATA%\Notepad++\plugins\ is not needed anymore.

Well, at most.

When Notepad++ gets installed, admin rights are required. If an administrator trusts his users and/or the community of Notepad++ plugin developers, he could select “Allow plugin installation to the user profile (%LocalAppData%)” during installation. As a result users could install plugins without admin rights later on. I think this was the use case of this option in Notepad++ versions prior to v7.6.

I don’t know, but I think this could be the most uncommon use case. It wouldn’t be that bad to loose this feature.

donho

FYI, the plugins loading schema has been modified again. Please recheck the 1st post of this thread.

donho

@Meta-Chuh

grey out “Don’t use %APPDATA%” if the selected path matches %PROGRAMFILES% or %PROGRAMFILES(X86)%

I will see what I can do about it.

The 2nd point will be solved in the next release (see new schema of the first post).

Meta Chuh

@donho

thanks a lot, much appreciated
your edit (28 November 2018) looks perfect, clean and straight forward

so if i’m correct, you can and will remove ${If} $arePlugins4AllUsers == “true” and all pluginsForAllUsers.xml sections
as they are not necessary for anything anymore, correct ?
if yes, it’s a perfect cleanup

greetings
MetaChuh

donho

@Meta-Chuh said:

so if i’m correct, you can and will remove ${If} $arePlugins4AllUsers == “true” and all pluginsForAllUsers.xml sections
as they are not necessary for anything anymore, correct ?
if yes, it’s a perfect cleanup

Yes, they are not necessary anymore. I will do a clean up

donho

FYI: The 1st post of this thread has been updated: new plugin list locations are added.

OldMcWeb

Hi,
im new here and like to contribute some thoughts from a user perspective.

In the current case as a user I get the changelog with a link to https://notepad-plus-plus.org/features/plugin-admin.html
Then I start searching for the PluginAdmin, found out that i need admin privileges.
That’s a debatable move, but ok I can understand the thoughts behind.
Then I found that my plugins are under the admin profile AppData.
Ok makes sense to me, but now i find this thread telling me that things will totally change in the next release again.

As a idea:

Make it configurable where your plugins are stored. Maybe from the setup and in an config file.
Put more Info for this changes in the changelog, the link to https://notepad-plus-plus.org/features/plugin-admin.html
helps but is only a part of the solution
Maybe add a menu item in [?] -> GotoPluginFolder

Don’t get me wrong, I don’t want to criticize your hard work, but I like to show that the last update was very confusing for probably lot of users.

MrOuzo

I use Notepad++ many years, with many plugins and config files. I have 2 points to store all Programm ,plugins and configuration… now i have so sort and show to all config and whatever that it comes into the right location… its a bad thing and i stay on lower than 7.6. so i know it works.
If its a new installation and you have no good working configuration, i say its ok to install this new worst admin plugin. For a updated install its better to use all the locations as is it… for every dll-plugin a directory with his own name…brrrr

Marc66

It took me forever to get back to a working configuration after the Plugin folder and approach changed in 7.6. I was able to install 2 additional plugins manually, because installation from the plugin admin doesn’t work (it just freezes and never completes). I ran plugin admin and saw there were updates, so I updated them and it simply removed them.

Why break something that has been working for years?

I searched for an alternative and happily moved to PSPad: lightweight and has compare and hex viewer feature out of the box. I’m done with Notepad - -

OldMcWeb

@Marc66 Well things change and change is not a bad thing.
But this change hits the user a bit unprepared.

PSPad … naaaa…Closed source is not a option for me.

Stan Petit

Hi all.
Could you write something clear about the future of NPP-PORTABLE-VERSION, in regard to the new plugins location strategy?
To keep the Plugins Menu list “as minimal as can be”, I got the habit to run several portable Notepad++ in parallel : no use to load plugins that are not necessary.
So, what about the ability to run different configurations of Notepad++ depending on the project ?
Best, Stan.

Meta Chuh

@Stan-Petit

everything stays within the np++ portable folder in the future too
the only thing that changed since 7.6 ist that you have to have a subfolder for the dlls inside the plugin folder

example for versions below 7.6:
<NPP_INST_DIR>\plugins\MyPlugin.dll

example for 7.6 onwards:
<NPP_INST_DIR>\plugins\MyPlugin\MyPlugin.dll

very important: you can put the portable version’s folder anywhere (usb drive, desktop, etc.) but not inside C:\Program Files or C:\Program Files (x86) but this restriction has been the same in older versions too

also please have a look again at the first post:

Notepad++ loads plugins from: <NPP_INST_DIR>\plugins\
plugins list dir : <NPP_INST_DIR>\plugins\Config\
plugins’ config dir: <NPP_INST_DIR>\plugins\config\
because Notepad++ installed on: wherever (except in %PROGRAMFILES%\Notepad++) with doLocalConf.xml

Meta Chuh

@Meta-Chuh said:
currently we have to answer these scenarios again and again:
…
possible solutions:
grey out “Don’t use %APPDATA%” if the selected path matches %PROGRAMFILES% or %PROGRAMFILES(X86)%

@donho
btw: thanks for your commit
(Make installer more coherent for the option doLocalConf.xml) 👍

very much appreciated

ldlx

This is a security nightmare!

All users are allowed to write new files (and so DLLs) to programdata, but only the creator-owner is allowed to change a file by default. So updates of a plugin can be installed by the user that installed the plugin or by an account that as administrator priviligues. And every user is allowed to install new plugins for all users. Is this really the intended behaviour or will the Notepad++ installer change the NTFS right so that only users with administrator priviligues are allowed to install plugins/updates?

Meta Chuh

@ldlx

And every user is allowed to install new plugins for all users.

not true, you need to have administrator rights to install plugins via plugins admin.

furthermore it was the wish of almost all it pro’s within this community to have a single plugin location for all users instead for each user manually, as they need it for a simple and quick deployment.

dinkumoil

@Meta-Chuh

I have to second @ldlx . What he wants to point out is that every user can drop new e.g. DLL files in any subdirectory of %ProgramData%. Normal Windows users are only prohibited to delete, change or overwrite already existing files which have been created by another user.

Thus it is indeed a security hole. Me and other people already pointed that out in the past. But it seems to be more important to be able to provide a Windows Store app (the reason for the whole plugin relocation) than to follow common security guidelines.

I already wrote down my thoughts to UWP (Windows Store) apps in this comment. When this specification has been designed, the author(s) had obviously not in mind that there could be apps with a plugin interface like Notepad++. This kind of apps is not suitable for UWP because they have no other choice than to store executable code (the plugins) in some kind of user profile which are unsecure locations.

Maybe Microsoft will change the UWP app specification somewhere in the future and will forbid to store executable code in unsecure locations. Then all the hassle we are faced with currently will be for nothing.