Community
    • Login

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

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    117 Posts 22 Posters 94.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • chcgC
      chcg
      last edited by

      Regarding security:
      Checking the hash of the entire zip is also done by the 32bit PluginManager.
      Additionally it should be forced to use https download locations.
      Gup.exe companion libcurl needs to be up to date to avoid CVEs/bugs from that side.

      donhoD 1 Reply Last reply Reply Quote 2
      • donhoD
        donho @dinkumoil
        last edited by donho

        @dinkumoil said:

        I found another pitfall in the new PA.
        The new PA doesn’t init a restart of Npp. Thus after installing plugins their initialization code isn’t processed and they don’t work (tested with my AutoCodepage plugin).

        Nice catched! This bug is fixed now in 2 (32 & 64 bit) Notepad++ debug binaries. NPPN_READY is sent to the installed plugin after being loaded:
        https://github.com/notepad-plus-plus/notepad-plus-plus/commit/c531a4d42a9b4afe0136d48fdc3c376f67067bb0

        Both binaries are available to be downloaded.

        1 Reply Last reply Reply Quote 4
        • dinkumoilD
          dinkumoil
          last edited by

          @donho

          Tested and worked.

          1 Reply Last reply Reply Quote 1
          • chcgC
            chcg
            last edited by

            For NppFTP the NPPN_READY doesn’t solve it completely. Now the docking and the message window are constructed/ visible, but the content is still not there.
            Maybe there is another difference to the start of n++ itself.

            1 Reply Last reply Reply Quote 3
            • dinkumoilD
              dinkumoil
              last edited by

              @donho

              The new plugin PA has some structural problems:

              1. The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.
              2. After plugin installation Notepad++ is not restarted. That seems to be nice at first glance but causes serious problems.

              In summary this means a maintenance nightmare for all plugin authors:

              • Because of 1. most of the plugins have to be repackaged.
              • Because of 1. plugin authors have to change access paths for additional files their plugins need to function properly. Despite that these code changes mostly should be easy to do it means some effort of work and time for plugin authors.
              • Because of 2. even more effort is required to fix the problems caused by that point. These code changes require debugging and maybe restructuring of code.

              In my opinion its worth to think about the current concept of the new PA. Wouldn’t it be better to provide a solution that is backward compatible with the existing PluginManager? This way it would be possible to provide all existing plugins seamlessly to the users instead of encumber them a long lasting transition period. Furthermore I’m sure that there will be a bunch of useful plugins which never get updated and thus will be lost for the community.

              dailD donhoD 2 Replies Last reply Reply Quote 2
              • dailD
                dail @dinkumoil
                last edited by

                @dinkumoil

                I fully agree with everything said above. I started checking into this and ran into the exact same problems. Some don’t effect me, but especially the restructuring of the zip files is going to be a pain.

                I am curious why the zip files need to have another folder inside. Nearly all zip files for plugins have been created for the pre-existing Plugin Manager. I’m not arguing for keeping 100% backwards compatibility but I would suggest using a packaging scheme which most plugins are already designed for unless there are very good reasons why another scheme is needed.

                donhoD 1 Reply Last reply Reply Quote 2
                • dinkumoilD
                  dinkumoil
                  last edited by

                  @dail said:

                  I am curious why the zip files need to have another folder inside.

                  Well, this makes the unpackaging code for the plugin ZIP files very simple… ;-)

                  A possible (and still simple) solution would be to modify the unpackaging code so that it unzips the content of the plugin ZIP files directly to the Npp plugins folder. But even that would not be satisfying. I’m sure that there are plugins whose ZIP file structure is not a mirror of the structure of their files and folders on the harddisk after installation (e.g. my plugins are of this kind).

                  That’s the reason why I demanded backward compatibility of the new PA to the old Plugin Manager. We need backward compatibility at minimum at the ZIP unpackaging level. That means the new PA should be able to recognize and execute commands similar to the ones in the installation node of the old Plugin Manager’s XML plugin list.

                  dailD 1 Reply Last reply Reply Quote 1
                  • dailD
                    dail @dinkumoil
                    last edited by

                    I understand the desire to have 1 folder containing everything for 1 plugin…this makes things simpler to manage/maintain, but this does not work for some plugins

                    @dinkumoil said:

                    Well, this makes the unpackaging code for the plugin ZIP files very simple… ;-)

                    What I’m referring to (1 plugin per folder) wouldn’t be that much harder at all. Just the difference between extract a zip directly, or creating a folder first then extracting the zip into it. But yes I understand what you mean if it wants to be compatible with the other plugins.

                    1 Reply Last reply Reply Quote 0
                    • donhoD
                      donho @chcg
                      last edited by donho

                      @dail said:

                      Can’t you just hash the entire ZIP file itself? That way you know everything is as expected.

                      @chcg said:

                      Regarding security:
                      Checking the hash of the entire zip is also done by the 32bit PluginManager.

                      Checking Zip package’s sha-256 hash has been implemented in the testing binaries:
                      https://notepad-plus-plus.org/pluginListTestTools/

                      (We need both notepad++.exe and GUP.exe for this new behaviour)

                      Thank you guys for the suggestions.

                      1 Reply Last reply Reply Quote 2
                      • donhoD
                        donho @dinkumoil
                        last edited by donho

                        @dinkumoil said:

                        The new plugin PA has some structural problems:

                        1. The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.
                        2. After plugin installation Notepad++ is not restarted. That seems to be nice at first glance but causes serious problems.

                        The PA’s design is for the future but not for the past, and KISS (keep It Simple Stupid). By giving each plugin its own folder, not only it makes plugins’ deployment easier, but also plugin can avoid to have complicate folder structure.

                        The 2nd point you mentioned is a bug, will be fixed in the future.

                        Because of 1. most of the plugins have to be repackaged.

                        It’s done for once, not a “maintenance nightmare”.

                        Because of 1. plugin authors have to change access paths for additional files their plugins need to function properly. Despite that these code changes mostly should be easy to do it means some effort of work and time for plugin authors.

                        It’s also done for once. OTOH the plugin folder should be used to store its own binaries or data, not user’s config file. The path of plugin config file should always be %APPDATA%\Notepad++ \plugins\Config since plugin folder will be erase entirely during its update.

                        1 Reply Last reply Reply Quote 1
                        • donhoD
                          donho @dail
                          last edited by

                          @dail said:

                          but especially the restructuring of the zip files is going to be a pain.

                          Why will it be painful? Could you elaborate?

                          I am curious why the zip files need to have another folder inside. Nearly all zip files for plugins have been created for the pre-existing Plugin Manager. I’m not arguing for keeping 100% backwards compatibility but I would suggest using a packaging scheme which most plugins are already designed for unless there are very good reasons why another scheme is needed.

                          Indeed, it could be created by GUP.exe while the deployment. What’s the scheme for the most plugins then?

                          1 Reply Last reply Reply Quote 0
                          • dinkumoilD
                            dinkumoil
                            last edited by

                            @donho said:

                            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).

                            1 Reply Last reply Reply Quote 1
                            • oleg-shilo81O
                              oleg-shilo81
                              last edited by

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

                              1. 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)
                                
                              2. 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.

                              3. @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?

                              4. 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?

                              1 Reply Last reply Reply Quote 2
                              • chcgC
                                chcg
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 2
                                • oleg-shilo81O
                                  oleg-shilo81
                                  last edited by

                                  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).
                                  
                                  1 Reply Last reply Reply Quote 2
                                  • donhoD
                                    donho
                                    last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 2
                                    • dinkumoilD
                                      dinkumoil
                                      last edited by

                                      @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:

                                      1. 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.

                                      donhoD 1 Reply Last reply Reply Quote 2
                                      • guy038G
                                        guy038
                                        last edited by 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

                                        1 Reply Last reply Reply Quote 2
                                        • dinkumoilD
                                          dinkumoil
                                          last edited by

                                          @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.

                                          1 Reply Last reply Reply Quote 3
                                          • guy038G
                                            guy038
                                            last edited by

                                            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 !

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post
                                            The Community of users of the Notepad++ text editor.
                                            Powered by NodeBB | Contributors