New Plugins Home (Round 2)

V S Rawat

side note:
the config file is called config.xml file located at %AppData%\Notepad++\config.xml of an installed version, and located at npp.7.x.x.bin\config.xml of a portable version.
it’s just like an “ini” file, but with a different, (probably) more readable syntax, as it is more structured and segments are foldable for easier reading if you want to analyse a certain part of it.

disagree.

xml files have hard fixed structures and use additional terms that are strange to non-programmer users.

ini files are normal text files that are easy, having
[Sectionname]
Variable1=value1
Variable2=value2

These are much easier to understand and edit by a common user who doesn’t know any programming.

by making elementary use of npp difficult to non-programmer users, we are limiting npp’s prevalence and popularity.

My this complain is million time amplified for defining shortcuts and creating macros due to the xml structure.

Thanks.

Meta Chuh

@V-S-Rawat

if you don’t want to compile notepad++ yourself, you can go to the notepad++ commit page at github like shown on the screenshot below, and do a mouse click on the green “check” on any commit that might interest you.

Imgur

after you clicked the green check, press “details” which will lead you to the appveyor page as seen on the next screenshot.

Imgur

there you click on your desired release configuration, like Configuration: Unicode Release; Platform: x64 and click on artifacts on the left as seen here:

Imgur

now click on Notepad++.X64.Unicode Release.exe of this example to download it, and copy it to your notepad++ install or portable folder (same place where your current notepad++.exe is located).

now start notepad++ by double clicking on the Notepad++.X64.Unicode Release.exe that you’ve just placed there.

… happy testing 😉😉

V S Rawat

Thanks for elaborate guidance, I was not aware of that.

But why should I do it? What is a markup language and how does that help me in which of my requirements? (By any chance, are you believing me to be a computer wizard? Wrong assumption, dear sir :-) )

Thanks.

Meta Chuh

@V-S-Rawat

But why should I do it? What is a markup language and how does that help me in which of my requirements? (By any chance, are you believing me to be a computer wizard? Wrong assumption, dear sir :-) )

you asked:

latest builds? how do you get them? beta testing or RC? Privileged one. :-)
download page still has Jan 1 release when I last saw that.

and you get an answer, that’s the way it should work 😉

btw: due to your tourette posting syndrom of today 😂😂😂, i’d suggest it’s better if you open your own thread for any further of your personal questions, this one is getting quite unreadable.
(my apologies to all readers)

Shamu35 NPP

How to Install plugins as non administrator user?

Option:
Install NPP into “%ProgramFilesx86%”. But during install or upgrade of a plugin, there will be displayed an UAC dialog which prompts for an admin accout. Therefore this is not a possible option.
Option:
Install NPP into “C:\Notepad++” and add “doLocalConf.xml” into this folder. Additionally give write access for the users group for this folder. The users (non administrators) are now able to install or upgrade plugins without an UAC prompt.
So far so good, but the main problem is, that now the configuration files are also located in “C:\Notepad++” and not in the userprofile anymore.
This leads to problems on shared computers which are used by different users. They don’t have their own configuration of NPP anymore.

Is there a different solution which I don’t know for solving this problem?
The main requirement is: Our users (which are not admins) should be able to install plugins by themselves.

Artem Sh.

@Shamu35-NPP said:

The main requirement is: Our users (which are not admins) should be able to install plugins by themselves.

This is critical for us as well.

PeterJones

@Shamu35-NPP & @Artem-Sh :

If it is critical for users to be able to install plugins by themselves, either give them local-administrator privileges, or install in an alternate location: if you use the installer, but put it in (say) c:\usr\apps\Notepad++ instead of c:\program files\notepad++, then they should have the write privileges necessary to install plugins themselves.

The reason I suggest this workaround, rather than agree that it should be changed: you aren’t the only one with a critical requirement. Others have a security-critical requirement of users not being able to install plugins, which is the exact opposite of your requirement. So, if you have admin privileges locked down, the options are to install into program files to protect notepad++ and prevent user-installed plugins, or install somewhere else with write-privileges to allow user-installed plugins, or to use a portable edition with doLocalConfig.xml to keep everything bundled in one writeable directory (or protected directory, if that’s what you prefer).

My workplace uses Avecto Defendpoint (and I’m sure there are other similar), which allows locking down certain Admin tasks, but allowing others; so, when I try a UAC action, Avecto Defendpoint checks my privileges, and if I’m allowed to do that local-admin task, it lets me, otherwise it prevents me. Maybe something like that would work to grant partial Admin privileges to your users. I am not an expert on the IT/Admin side of things, so that’s about as much about Avecto Defendpoint as I know.

Shamu35 NPP

@PeterJones said:

or install in an alternate location: if you use the installer, but put it in (say) c:\usr\apps\Notepad++ instead of c:\program files\notepad++, then they should have the write privileges necessary to install plugins themselves.

This doesn’t work! There is still an UAC prompt during installation of a plugin although I give write permissions for this folder. Additionally it needs doLocalConf.xml but this leads to problems on shared computers, because all plugins are installed in the installdir of NPP and not in the userprofile. I explained this already as “2. Option:” in my posting above.

you aren’t the only one with a critical requirement. >

Yes of course. But it had worked for years and now it’s broken for my needs and I have not found a solution for this new situation. Currently I’m not able to upgrade NPP to Version =>7.6

PeterJones

@Shamu35-NPP ,

This doesn’t work!

No need to yell at me. I’m a volunteer, spending my own time to try to help fellow users of Notepad++. I’m trying my best, but since I’m not on your computer, I cannot tell what problems you may or may not have.

Ignoring the UAC issue right now (that seems like a bug in the installer, to me; it shouldn’t need UAC to install in a non-program-files location, but we can come back to that). When you say “additionally, it needs doLocalConf.xml” when you installed into a non-protected area, what did you mean by that? What didn’t work if you don’t doLocalConf.xml?

Currently I’m not able to upgrade NPP to Version =>7.6

So is there a reason you can’t just stick with v7.5.9? With some apps, like internet-facing browsers, it’s good to always stay on top of updates for security reasons. But for an app like a fancy text editor, it’s not so dangerous to just stay on a version that already works for you. Turn off auto-updates, and stick with the version that’s “good enough”, that does what you want, even if it’s not the latest-and-greatest. There haven’t been a lot of killer-features added, mostly just incremental changes recently. Personally, if i weren’t trying to help people on the forum, I would still be on 7.5.8 right now.

Vitaliy Dovgan

I have a tricky question. What if one wants to create a plugin named “Doc” or “Config”? This plugin should reside in a folder with the corresponding name, right? ;)

Meta Chuh

@Vitaliy-Dovgan

you’ve just made my day 👍

😂😂😂

V S Rawat

@Vitaliy-Dovgan said:

:-)

alexhass

@donho: When are you fixing the plugins per user feature you have broken? Are you able to answer?

If auto-update files are not installed the PluginAdmin does not load. So nobody can install “per User” plugins.
NPP auto-update cannot disabled per machine.
Per user plugins cannot enabled in setup any longer. Why the hell?

I need:

Notepad++ auto-update disabled (per Machine). A config.xml in notepad.exe folder seems not working (tested).
PluginAdmin is required
PluginAdmin with Automatic Update
Plugins need to be installed “per User” to %APPDATA% (and not to %ProgramData% where users have no access what causes an UAC)
Need to be able to disable automatic-updates for specific plugins. e.g. AutoUpdate=0 in global config .ini files.
Plugins do not install per architecture. That means you cannot run x86 and x64 on same machine. Per user plugins currently colides. The folder structure need to be adjusted to have “%APPDATA%\Notepad++\x86” and “%APPDATA%\Notepad++\x64” folders.

Please repair Notepad++ ASAP so it can be used in Enterprise environments.

narutards

I’m admin in an enterprise environment and we’ve been using Notepad++ for a while. But with the latest changes I can no longer update the application because it would break basically every installation/“usage pattern” our users have adapted to.

We’ve been deploying Notepad++ updates with Microsoft SCCM and then placing the “allowAppDataPlugins.xml” file in the program directory under “%ProgramFiles%\Notepad++”, allowing our users to install whatever plugin they want in their own profile under “%AppData%\Notepad++\plugins”. We do that because obviously we don’t want to give users admin privileges to install plugins in the program directory. We also don’t want to install plugins for the users ourselves. The support overhead would “kill” us.

Is there any way to get this functionality back?

Load global plugins from “%ProgramFiles%\Notepad++\plugins”
Additionally load user installed plugins from “%AppData%\Notepad++\plugins” when “allowAppDataPlugins.xml” exists in “%ProgramFiles%\Notepad++”

Meta Chuh

@narutards

this recent thread >>> install notepad++ plugin without admin rights <<< covers how to deploy/install 7.6.3 and above, so that users are able to install plugins without admin rights.

it also includes a working deployment batch script as example.
also feel free to open a separate new topic on your case, if you need different information or examples.

if your questions don’t differ much from the original poster’s, you can comment on the same thread from above as well.

Vitaliy Dovgan

With the new structure of the plugins folder, I’m wondering whether an archive with a new version of a plugin should reflect this new structure?
Let’s take NppExec plugin as an example. The old structure of its archive (NppExec_*_dll.zip) is:

doc\NppExec…
NppExec*.h
NppExec.dll

Should it now be changed to the following? -

doc\NppExec\…
NppExec\NppExec\*.h
NppExec\NppExec.dll

Such structure will reflect the current Notepad++'s expectations regarding its plugins and will need the new Plugin Manager’s script that deploys NppExec to be modified accordingly.
Is it what is expected? Just want to clarify this in advance.

Meta Chuh

@Vitaliy-Dovgan

this is a very good question.

my first (unconfirmed and untested) thought is, that if the plugin’s release .zip structures are altered, they will be extracted as is, resulting in a doubled subfolder for each plugin (e.g. NppExec\NppExec\NppExec.dll).

also as there is probably no possibility, that all plugin developers change the structure at the same time, plugins admin would need to have an intelligence, to be able to know where the plugin’s .dll is located within the plugin release zip’s folder structure.
(alternatively, plugins admin would need some kind of extra bool flag, which tells it something like: newFolderStructure=true)

very tricky everything is, intriguing and interesting and very tricky.

Alan Kilborn

@Meta-Chuh said:

very tricky everything is, intriguing and interesting and very tricky

…and totally worth it…one little ad…

Vitaliy Dovgan

I know what to do. Two versions of the *dll.zip will be created: one with the old and another one with the new folder structure inside. So the Plugins Manager will be able to use either one. And finally, as time passes, just one version of the *dll.zip will survive.

V S Rawat

@Vitaliy-Dovgan said:

I know what to do. Two versions of the *dll.zip will be created: one with the old and another one with the new folder structure inside. So the Plugins Manager will be able to use either one. And finally, as time passes, just one version of the *dll.zip will survive.

I think Plugin Manager will still cater to old plugin arrangement.

It is plugin Admin that is managing pluings as per new arrangement.