New Plugins Home (where Notepad++ will load from)
-
FYI: The 1st post of this thread has been updated: new plugin list locations are added.
-
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.
-
-
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 -
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 - -
-
@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.
-
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. -
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 folderexample for versions below 7.6:
<NPP_INST_DIR>\plugins\MyPlugin.dllexample for 7.6 onwards:
<NPP_INST_DIR>\plugins\MyPlugin\MyPlugin.dllvery 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 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
-
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?
-
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.
-
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.
-
@Meta-Chuh said:
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.
EVERY USER can store files to programdata. But only the creator-owner can change/save/delete files that he created.
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.
There’s a good location where only administrator users can write - the folder where the program is stored in %programfiles% - only administrative users can write to that location.
-
@dinkumoil
if you remember, the original proposed locations were both at %LOCALAPPDATA% and switchable to an all user installation at %PROGRAMDATA% or %PROGRAMFILES%
but so many people (the ones who posted actively, not me) wanted it to be as it is now, simple and a single plugins folder for all users.now we have a situation where everyone originally wanted chocolate ice cream and now that it’s served they’d prefer vanilla.
do you have an idea what’s best to do now ?
-
@dinkumoil Windows Store Apps are provided on a per-user base - which are placed inside the user profile (afaik). It makes no sense to provide plugins on a per-machine base when the installation is on a per-user base.
@Meta-Chuh said:
@dinkumoil
if you remember, the original proposed locations were both at %LOCALAPPDATA% and switchable to an all user installation at %PROGRAMDATA% or %PROGRAMFILES%
but so many people (the ones who posted actively, not me) wanted it to be as it is now, simple and a single plugins folder for all users.now we have a situation where everyone originally wanted chocolate ice cream and now that it’s served they’d prefer vanilla.
do you have an idea what’s best to do now ?
keep it the same way as before:
- users can install there plugins in %appdata% (or %localappdata%, but I believe it is %appdata%) - when “allowAppDataPlugins.xml” is present in the program files folder
- all-users-plugins can be put in the program files-plugin folder.
imho: it doesn’t make sense to install programs on a per-user base (UWP-apps) and to provide plugins to all users on a per-machine base (in %programdata%).
-
This is not a question of vanilla and chocolate ice cream.
@donho was only willing to implement loading plugins from a specific user profile or from the AllUsers profile (the %ProgramData% directory). And the reason for the relocation of plugins is, that he wants to publish an UWP version of Notepad++, which requires in turn that the installation directory of that (future) app is immutable after its installation. That is what @donho said to that thing, I have to trust him because I don’t know anything about the details of UWP apps.
I was even not involved in the discussion about “store plugins in %LocalAppData% or in %ProgramData%”. My most important point was, that it would be a bad idea to put the plugin list into a specific user profile. That would mean that only the user who has installed Notepad++ would have a plugin list.
do you have an idea what’s best to do now ?
What I always said: Forget this UWP app thing and revert plugin storage location back to the installation directory. But this will never happen. The only thing I can do is to try to influence the further development in such a way that it results in a product that is first and foremost convenient for me as a user and plugin developer.
-
@ldlx said:
will the Notepad++ installer change the NTFS right so that only users with administrator priviligues are allowed to install plugins/updates?
Yes, you are right about it. The right to add files of this folder should be Admin only, and this feature will be in the next release.
-
@donho said:
The right to add files of this folder should be Admin only, and this feature will be in the next release.
So you will have to remove access rights inheritance from the directory
%ProgramData%\Notepad++\pluginsbecause the ability for normal users to write to this directory is inherited from the%ProgramData%directory. Does NSIS provide a feature to change that?If you remove access rights inheritance via Windows Explorer’s Properties dialog, you can choose to remove all existing inherited acces rights or to convert them into explicit access rights for the folder in question.
If you choose the latter one, you have to delete unwanted access rights (the ones for owner/creator and normal users) after that. If you choose the first approach you have to carefully design and configure your own set of access rights for the directory.
In all cases you have to activate inheritance of the newly set acces rights to files and directories inside the directory in question.
-
We are a University and using NPP on many student computers. The users are not Administrators. They are using different plugins which we can not preinstall.
The problem is, that they are not able to install or update plugins with Plugin Manager.
They will be prompted by an UAC dialog, but there, they can not enter an administrator account because they don’t have such an account.The plugin installation has worked until NPP 7.5.9 for non admin users but now this is not possible anymore!
This means, we can not update NPP to newer versions anymore.
Is there a solution planned for this problem? -
Well, if the switch to the new plugin hosting model and Plugin Admin would be complete, I would say you can use portable versions of Notepad++ for your students. But unfortunately currently there is the limitation that there is no Plugin Admin in portable versions.
But there is still a possible solution, have a look at this posting and the following ones. But this implies some oddities you will recognize by yourself.
-
@dinkumoil said:
Well, if the switch to the new plugin hosting model and Plugin Admin would be complete, I would say you can use portable versions of Notepad++ for your students. But unfortunately currently there is the limitation that there is no Plugin Admin in portable versions.
But there is still a possible solution, have a look at this posting and the following ones. But this implies some oddities you will recognize by yourself.
Maybe it isn’t possible or managable that there’s a copy of Notepad++ in every user profile on a number of different computers. Maybe running executables in unsafe locations (everything except %programfiles% or %systemroot%) is forbidden.
