New Plugins Home (Round 2)
-
@klou ,
… and THEN parses and loads from the user profile
A lot of people were against the possibility of letting the user install binaries in its profile because of the possible security issues.
If you are admin and want to restrict users from installing anything without having the right permissions (or you simply need to authorize the install of any binary on the machine) how can you do that in your case? -
I second @klou . Even I suggested earlier the same. This way we allow users to use the notepad++ extend-ability while not disturbing other user on the same machine (as user A may like plugin X while user B may like Y plugin for same task. Example multiple plugins of json exist, so we should respect users choice on the same machine e.g. on server or common pc.)
A lot of people were against the possibility of letting the user install binaries in its profile because of the possible security issues.
This should not be a concern at all. If one does not like to load plugin other than the installation dir. I flag can be used which will disallow that.
P.S. not only Firefox, may applications follow this model and those are secure too.
-
@pnedev ,
Well, that’s a question of what the admin is trying to control, as well as his definition of “installed.”
Going back to the Firefox model, they had an admin setting called “Addon Scopes” which allowed the admin to allow global scopes, user scopes, or a combination of the two. Granted, a lot of this might be no longer valid with Web Extensions and all that, but I’m using this as an example.
If the admin wants to restrict binary/executable launch from the User Profile, then that essentially eliminates all “portable” apps, as well as DLLs, etc. Which means that the User can’t install Fonts to their own profile, or run Bomgar or GotoMeeting sessions. But does “installed” mean “place an executable in an allowed location and run it”? Or is it “place in a system-level location and make available to all users to launch”? If it’s the first, then such control is enforced by something other than Notepad++.
But what are we (as admins) trying to protect by having these restrictions? Executables launched from the User Profile should already be sandboxed, assuming that the user doesn’t have admin privileges.
-
Thanks for that! Maybe sad, that loading plugins from %appdata% per XML-file in %programfiles% is gone (i never needed it personally, but maybe for some environments)
-
@Meta-Chuh said:
i hope you don’t mind my question now that you mentioned
nppPluginList.dll:
how will faster nppPluginList.dll updates, independent of notepad++ releases, be handled in the future ? (nothing fixed, just brain storming probabilities)
will you add the possibility to update to a new nppPluginList.dll, downloading it from a repo if you hit a future “check for updates” button within plugins admin ?
or are there any other ideas or caveats on that topic ?These features will be supported in the future.
but is it possible to load plugins from TWO locations?
I’ll consider it but I promise nothing.
-
-
@klou ,
Thanks for elaborating.
My post was just a reminder that a lot of people involved in administration were against such feature.What about the case when you have the same plugin installed in both places (in N++ install dir and in the user profile)?
-
… If one does not like to load plugin other than the installation dir. I flag can be used which will disallow that.
The flag you are talking about should be a installation time choice, correct?
-
thanks @donho
i’ve seen that @pnedev 's Add ‘Open Plugins Folder…’ command has not been merged yet, so it’s not present at the current build.
will his ‘Open Plugins Folder…’ be present at the next release ?
i suppose it would make things easier to migrate plugins (for regular users), if they upgrade to 7.6.3.note: if you don’t like ‘Open Plugins Folder…’ to be at the plugins menu directly, it could be an idea, to move this button inside ‘plugins admin’.
which would also be a logical place to search for it and equally easy to find (presupposed that the user has plugins admin enabled). -
@pnedev said:
… If one does not like to load plugin other than the installation dir. I flag can be used which will disallow that.
The flag you are talking about should be a installation time choice, correct?
Yes. You are right.
-
<NPP_INST_DIR>\plugins\config\
It is ok with me if NPP_INST_DIR remains windows default location for installing any software, i.e. “Program Files” or "Program Files (86)
As we already have npp installer and we can reinstall npp to that location at any time, we don’t have to take backup of that folder.Plugins and Plugin-list will be aside of notepad++.exe so no more sharing problem for all users, nor the security issue.
Excellent, I have been begging for that for eons. Thanks a gig.
With this change, I will keep my plugins well separate from c:\windows as well as from c:\Users, I will keep them in E:\MyData\npp64\plugins
As I need to take backup of that.Future installers should not touch or add or delete to this folder.
I think you should not even provide default 4-5 plugins bunduled in the npp installers.
If I need to install or remove any plugin, I will do it manually through within npp Plugin Manager or Plugin Admin.
The applied plugin folder structure <PLUGINS_HOME>
How do we define our <PLUGINS_HOME> folder?
Can we define it from within npp Settings/ configuration, or can we define it in .ini file?
Other issue is PythonScript plugin that was still using npp installation folder, and putting its huge files and one dll and help files there, even when programdata was being used. How would you handle that unless that plugin developers release update?
those are huge files and we don’t need to take backup of them as they are already present in pyscript installer, it will be better if they remain in npp installation folder, or maybe they may be installed as a separate program on windows using a separate program files folder so that that plugin becomes available to entire windows, whoever cares to use it anywhere else.
if any plugin’s huge installation/ help files are put in new <PLUGINS_HOME> folder, that will be proglematic for me.
Thanks.
-
My suggestion was:
The way you are now giving a “<PLUGINS_HOME>” variable, you should also please consider giving a “<USERS_HOME>” variable that a user can set to move his entire c:\USERS<name>\APPDATA\Roaming\npp folder (or whatever the structure is) to elsewhere.
then, in my case, I will move that to E:\MyData\npp\profile folder.
Then, plugins’ c:\USERS location will automatically move to the above location.
Then I can use the same npp <USERS_HOME> across my w10 and w8.1 multiboot.
please have a look to firefox, thunderbird arrangements for moving entire user profile that way. My firefox profile is in E:\MyData\ff\ffprofile and My Thunderbird profile is in E:\MyData\tb\tbprofile and I have been using them for 10-20 years, across multiboot o.s.
Thanks.
-
I personally find the entire concept of doLocalConf.xml confusing and unnecessary.
new users must be getting confused about that, most might not be knowing that even for years of use of npp, the way it had been for me for years.
it should be done through a single variable in .ini file.
Would you like to share what is the benefit of this file over an .ini setting?
Thanks.
-
Many users don’t know what plugin is, and they will never use a plugin for years of using npp, so there is no point in making every user take the important decision about placement of plugins in programfiles or users\roaming right at the time of installation.
And once the user has made any decision in absence of full knowledge of the issue, there is no easy and obvious method of changing that from within npp settings.
I think this entire question about plugin location should be removed from installer, and the user should be able to install npp like he/ she installs other windows software, without having to making a tough far fetching decision right in the middle of first install.
Then, user should be able to decide from within npp settings, where he wants to keep plugins, if he ever wants to use a plugin. Otherwise, may be the user will never need to make such a decision for his entire life.
If a user changes the location of plugin_home or users_home from within npp settings, he should be asked whether he wants the existing contents of old folder to be moved to new location, and if he says so, it should be done. That new location might already have users previous setup of previous npp, if so, user should be warned that there are already similar files that would be overwritten, and he should be able to choose whether to copy/ move or not.
Thanks.
-
I am not comfortable with the suggestion of Meta Chuh and pnedev about “extra sub-folder per plugin” made in other thread.
every plugin should have one .dll then it can be kept without needing any folder hierarchy structure.
And most plugins do have a single .dll, except some, say, pythonscript.
But then the developers can define within the single plugin.dll where the other dlls or other help files or other installation files can be found, so why cramp plugin folder?
Even if a plugin has several dlls and one or more help or other files, plugin developers can name them with plugin’s initials, say, pyscript1.dll, pyscript2.dll, pyscript.hlp, meaning that ll files of a plugin should come together and should be identifiable readily by the user with plugin’s name. then users will not find any problem.
I think pyscript plugin has another file that has no relation to plugin name and we have to figure out where that came from and whether it is safe.
So, my suggestion is to remove that pluginnamefolder/pluginname.dll compulsion
billions of people in the world live in shared house and shared room, every human is not having his own single occupancy house or room, so why not get used to that common trend. :-) maybe if npp policy is followed, husband and wife will have to sleep in different rooms. :-)
Thanks.
-
hi @V-S-Rawat
I personally find the entire concept of doLocalConf.xml confusing and unnecessary.
i understand what you mean, but it is imperative that it exists in the way it does now.
a little explanation:
if you don’t have doLocalConf.xml present at startup, notepad++ would look for aconfig.xmlfile inside of%AppData%\Notepad++\to read it’s settings.
if it does not exist, it will create one.
now if the dolocalconf setting is within the config.xml, it would cause a paradoxon, as notepad++ would look up at %AppData% that it should behave as a “portable” version which is supposed to get it’s config from %InstDir% instead of %AppData%.the existence of a file called
doLocalConf.xmltriggers notepad++ to read and create everything within it’s own folder, and it also triggers where notepad++ will read it’s config file from (and create/write to). -
I might have a 64 bit w10, and might have 32 bit w8, and I may have npp 32/64 bit in those.
so, if <pluginin_home> is single in both o.s, npp, I wil face problems when using same npp installation in both o.s.
of course, if I manually define different <plugin_home> for both o.s., but then if you are also considering to define a new <USERS_HOME>, then <plugin_home> will become fixed relative to this variable, and that single location can’t have both 32 and 64 bit plugins together.
so, my suggestion is while defining default <plugin_home>, it will become required if that can be kept separate for 32-bit and 64-bit, and future 128-bit and 256-bit so on.
Thanks.
-
But npp.ini (whatever the name is) has to remain in npp’s intallation folder in program files.
Why keep npp.ini file to a different location?
Even if we have kept a copy of our previous npp.ini file safe in our pc or in backup, we can copy that single file to npp’s intallation folder after installing it, then it can read all things from there.
Then how does that local.xml file help over .ini file. We have to create/ copy xml file also once?
-
Many users don’t know what plugin is, and they will never use a plugin for years of using npp, so there is no point in making every user take the important decision about placement of plugins in programfiles or users\roaming right at the time of installation.
that’s one of the reasons why a built in
plugins adminexists now.
plugins adminwill make sure that the users you mentioned, don’t have to care where to put their plugins, and it will put the (re)installed plugins to the correct locations, even if the location changes, as it is built from the same developers that decide the folder structures. -
@V-S-Rawat said:
I am not comfortable with the suggestion of Meta Chuh and pnedev about “extra sub-folder per plugin” made in other thread.
every plugin should have one .dll then it can be kept without needing any folder hierarchy structure.yes i know, and i understand your primary reasons, to keep the old plugins structure as it was, because all older plugins will just work out of the box, just the way they’ve always worked.
but i think you’ll like the new structure, once all transitions are over and everything has calmed down a bit.
and we will help you through your needs as always, like you are used to, to keep your system running.
