New built-in Plugin Admin (Plugin Manager) is ready

dinkumoil

The path of plugin config file should always be %APPDATA%\Notepad++ \plugins\Config since plugin folder will be erase entirely during its update.

I’m not talking about the config files. I’m talking about additional files the plugins need to function properly (e.g. DLLs, help files, documentation). Install in a test environment e.g. the plugins XML Tools, CS-Script, NppExec, ComparePlugin, MarkdownViewerPlusPlus and CodeAlignment. Then look into <Npp-installation-folder>\plugins and <Npp-installation-folder>\doc and you will see what I mean.

All these plugins create subfolders/store files in the folders mentioned above (DLLs, CHM help files, HTML and TXT files). With the new “One plugin - one folder” policy plugin developers have to change their code to cope with it (can take more or less effort). If they don’t do it the plugin ist lost for the community.

Repackaging of plugin ZIP files could be done by community volunteers but isn’t sufficient. Changing the code of foreign plugins and recompile them is much more complicated (obtain permission to fork, make adaptions to current development tools, analyse and understand the code, make required changes).

oleg-shilo81

Hi there, I am the author of CS-Script plugin and I would really appreciate if a few critical point as confirmed/elaborated.

A few recent changes to the plugin hosting model make it very difficult to maintain plugins. Can you please confirm if the new “One plugin - one folder” model is a final change? Currently I have the following plugin structure working OK while not strictly following the PluginAdmin model:
```
Notepad++
  \-- plugins
        \-- CSScriptNpp
              |-- CSScriptNpp
              |      |-- CSScriptNpp.asm.dll (managed)
              |      |-- CSScriptLibrary.dll
              |      |-- . . .
              |
               \-- CSScriptLibrary.dll (native)
```
From plugin-admin.html: The json file will be built into the a binary (nppPluginList.dll), which will be signed (for thes sake of security) and be included in the official distribution.
Does this mean that any plugin updates users will need to wait until Notepad++ is updated?
If it is the case, would it be more beneficial to have a separate release schedule for Notepad++ and for PluginList. SublimeText3 and VSCode has achieved this quite harmoniously. May be a similar model can be adopted for Notepad++ as well.
@doho said: The path of plugin config file should always be %APPDATA%\Notepad++\plugins\Config since plugin folder will be erase entirely during its update.
For years plugins\Config folder was used by the various plugins to store plugin specific configuration. It worked very well because Notepad++ and plugins’ configuration were completely decoupled. “erase entirely during its update” completely breaks the existing paradigm.
Is there any plans to to somehow reconcile the needs of Notepad++ and the plugins?
Is there any plans to replace ultimately misleading plugin initialization error message “This ANSI plugin is not compatible with your Unicode Notepad++ v7.5.9” with something more accurate?

chcg

See https://github.com/notepad-plus-plus/nppPluginList/pull/5. There I added a list of the currently available plugins from https://github.com/bruderstein/npp-plugins-x64/blob/master/plugins/plugins64.xml and the location of the main dlls within the existing zip files. Most of them are directly in the root dir of the zip.

oleg-shilo81

In my previous post the item #3 is invalid. Please ignore it. I misinterpreted the @doho’s quote.

@chcg, that’s great, I am glad you have aggregated all PluginManager plugins. But… does this mean that @doho will change his mind and update N++ implementation to allow plugin dll to be in the package root?

Currently the official N++ plugin admin description requires this:

Item #6: https://notepad-plus-plus.org/features/plugin-admin.html

The package should contain the named folder and the same name dll plugin inside the folder (for example: \myExtraordinaryPlugin\myExtraordinaryPlugin.dll).

donho

In order to be compatible with the most of existent packages, here’s new package folder structure rule:
The plugin (DLL) should be under the root of zip file (and only).

There will be no old plugin manager’s copy instructions. I try to KISS in new design of PA.

All the binaries are updated:
https://notepad-plus-plus.org/pluginListTestTools/

Please use them (both notepad++.exe & GUP.exe) to test with your plugin package, and let me know if any problem.

Thank you for your pertinent suggestions.

dinkumoil

@donho said:

The plugin (DLL) should be under the root of zip file (and only).

After testing the new binaries I want to precise this statement according to my experience.

The plugin DLL file should be placed at the root level of the ZIP file. It has to be the only DLL file on this level.
The root level of the ZIP file can also contain additional files and folders which will be copied to the users harddisk as well.
Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins\<plugin-name>.

Presumption: Additional DLL files needed by the plugin have to be placed in an arbitrary subfolder because the destination folder <plugin-name> gets named after the DLL file placed on the ZIP root level.

@oleg-shilo81 said:

From plugin-admin.html: The json file will be built into the a binary (nppPluginList.dll), which will be signed (for thes sake of security) and be included in the official distribution.
Does this mean that any plugin updates users will need to wait until Notepad++ is updated?

@donho already answered this question here:

The release of nppPluginList will be independent from the release of Notepad++, and in the future, Notepad++ will be notified once there’s a new release of nppPluginList and download it.

As well, nppPluginList will be maintained and released by people of community, since I’ll have not much vacant time for it.

guy038

Hi, @don-ho, @chcg, @dinkumoil, @dail, @oleg-shilo81 and All

Just a neophyte question, because I’m quite far from creating my own plugin: ;-))

After reading all your posts and in order to summarize, if I understand you, correctly, for a plugin named, say, abcde.dll :

It should be placed in the folder ..\Plugins\abcde
All other files and folders, necessary for the plugin, which were, initially located under ..\Plugins\Config\abcde ( or elsewhere ! ), will, now, be located under ..\Plugins\abcde

And so, in the long run, the config directory should disappear, shouldn’t it ?

Personally, I think that, if this new organization were implemented, it would be better because everything, regarding, for instance, the abcde.dll plugin, would be included in its own folder ..\Plugins\abcde :-))

Cheers,

guy038

dinkumoil

@guy038 said:

a plugin named, say, abcde.dll :

It should b placed in the folder ..\Plugins\abcde

That is correct.

All other files and folders, necessary for the plugin, which were, initially located under ..\Plugins\Config\abcde ( or elsewhere ! ), will, now, be located under ..\Plugins\abcde

No, files in the config folder stay there. Nothing changes.

And so, in the long run, the config directory should disappear, shouldn’t it ?

Personally, I think that, if this new organization were implemented, it would be better because everything, regarding, for instance, the abcde.dll plugin, would be included in its own folder ..\Plugins\abcde :-))

This would be a bad idea. At least for local installations of Npp the plugins own folder is stored in a proteced location (usually C:\Program Files\Notepad++\plugins\abcde). Thus the plugin wouldn’t be able to write to its own config file(s) because admin rights would be required to do that.

guy038

Hi @dail,

Thanks, for all your clarifications :-)

Regarding my last statement, I’m so used to have, on my laptop, several versions of N++, at a time, all located in a user-defined folder, not related with any system-protected area that I had just forgotten the particular case you were talking about !

donho

@dinkumoil said:

After testing the new binaries I want to precise this statement according to my experience.

The plugin DLL file should be placed at the root level of the ZIP file. It has to be the only DLL file on this level.
The root level of the ZIP file can also contain additional files and folders which will be copied to the users harddisk as well.
Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins<plugin-name>.
Presumption: Additional DLL files needed by the plugin have to be placed in an arbitrary subfolder because the destination folder <plugin-name> gets named after the DLL file placed on the ZIP root level.

Very accurate description you made. It will be included in the PA guide line if I’m allowed to use it.

dinkumoil

@donho said:

It will be included in the PA guide line if I’m allowed to use it.

Of course, feel free to do that.

Hsilgos

Are you sure you did your last changes to both versions of GUP and Android++?
For me seems that x64 works with new scheme, but x86 works with old

dinkumoil

@Hsilgos said:

For me seems that x64 works with new scheme, but x86 works with old

I’ve tested both 32 bit and 64 bit Notepad++ and both worked with the new scheme.

donho

@Hsilgos

Are you sure you did your last changes to both versions of GUP and Android++?
For me seems that x64 works with new scheme, but x86 works with old

Because you use Android++ instead of Notepad++.

Hsilgos

@donho Yes, Notepad++ for sure =D
The rest of message should be correct

donho

@dinkumoil Sorry, I didn’t read your description attentively. The correct info about packaging is following:

The plugin DLL file should be placed at the root level of the ZIP file.
The root level of the ZIP file can also contain additional files (DLL files or data files needed by the plugin) and folders which will be copied to the users harddisk as well.
Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins<plugin-name>.

The other DLLs can be at the root level with plugins DLL because Notepad++ will load only the dll has the same name as its containing folder. The other DLLs are just ignored.

chcg

Having a hash of the main plugin dll might be still of interest, if you want to provide a “safe” mode with just starting plugin dlls with correct sha-256 hash.

pnedev

@donho ,

I just noticed that when testing the NppGTags x86 plugin installation it was put in C:\Users\me\AppData\Local\Notepad++\plugins\NppGTags instead of C:\Program Files (x86)\Notepad++\plugins\NppGTags. It is working fine but I didn’t get the impression that it would be installed there.
Is that the intended behavior?

dinkumoil

@pnedev said:

it was put in C:\Users\me\AppData\Local\Notepad++\plugins\NppGTags instead of C:\Program Files (x86)\Notepad++\plugins\NppGTags

I did my previous test with portable installations of NPP, with a local installation I can confirm this behaviour. My plugins partially fail to work correctly, they don’t find their own DLL (required for extracting version information for the About box) and their documentation file anymore.

The current behaviour is caused by the fact that it was intentional to provide a method of plugin installation which requires no restart of Npp. Thus the plugin installer can’t copy the plugin files to the installation folder of Npp because usually this is a protected location and would require admin rights to do so.

Since we already discovered that there is a high risc that a restart-free plugin installation will cause problems with certain plugins (NppFTP seems to be one of these) @donho stated here that this behaviour will be changed. Thus in the future the installation folder should be <Npp-installation folder>\plugins\<plugin-name> again.

donho

@pnedev

Is that the intended behavior?

Yes, I confirm it.
From now on all plugins will be placed in its folder which has the same name, so that any data or dll that plugin needs can be placed arbitrarily in this folder.

I invite you to check the guide for being included in plugins list, it’ll be updated as soon as there’s any change of specs.