Plugins loading way has been changed in Notepad++ 7.6 (and upper versions)browsing

In future release version 7.6, which will be out in few days, there are some changes for plugins loading. Such change may create some impact after updating for users who have non-default plugins installed.

The change is about new organization of folder structure for plugins and simplification of plugins location. As result, some plugins won’t be loaded by Notepad++ after your update.

FOR PLUGIN USERS, to remedy this problem, after the update, you can :

Find the name of plugin you want to migrate in %PROGRAMFILES(x86)%\Notepad++\plugins\myAwesomePlugin.dll (or %PROGRAMFILES%\Notepad++\plugins\myAwesomePlugin.dll, according the achetecture of your Notepad++).

move the plungin myAwesomePlugin.dll from %PROGRAMFILES(x86)%\Notepad++\plugins\ to %PROGRAMDATA%\Notepad++\plugins\myAwesomePlugin\.

That’s it. Restart Notepad++ and you get your beloved plugins back.

FOR PLUGIN AUTHORS, a new shinning built-in Plugins Admin will be in Notepad++ version 7.6. This new component shows the list of available plugins, allows users to install new plugins and to update/remove installed plugins. Any plugin is welcome to join to the list, which is also an open source project hosted in the GitHub: https://github.com/notepad-plus-plus/nppPluginList/

That’s not the whole truth. Plugins which need additional files to function properly may or may not fail to work. It depends on how they currently determine the path to their companion files. The new plugin hosting policy requires that a plugin and all its companion files (except the config file) are installed to the same folder. This was not the case in the past.

Users which are facing problems with their legacy plugins should at first try to copy all files and folders belonging to the plugin in question to %USERPROFILE%\AppData\Local\Notepad++\plugins\myAwesomePlugin. If this doesn’t help they should contact the author of the plugin to request an update that adopts the new plugin hosting model of Notepad++.

For every plugin there has to be created a folder %USERPROFILE%\AppData\Local\Notepad++\plugins\<plugin-DLL-file-name>.

If a legacy plugin has had installed files or folders under <Notepad++-installation-folder>\plugins these files/folders have to be moved to %USERPROFILE%\AppData\Local\Notepad++\plugins\<plugin-DLL-file-name>.

If a legacy plugin has had installed files or folders under <Notepad++-installation-folder>\plugins\doc these files/folders have to be moved to %USERPROFILE%\AppData\Local\Notepad++\plugins\<plugin-DLL-file-name>\doc.

Details to some plugins

The AutoCodepage and AutoEolFormat plugins should be updated via new Plugin Admin because they are not able to find their own binaries and their documentation files. The same is true for CustomLineNumbers plugin but there is no update available yet (2018-11-05).

The BookmarkManager plugin has had installed a directory <Notepad++-installation-folder>\plugins\images. This has to be left there.

The XmlTools plugin has had installed additional DLL files in <Notepad++-installation-folder>. These have to be left there.

That’s not the whole truth. Plugins which need additional files to function properly may or may not fail to work. It depends on how they currently determine the path to their companion files. The new plugin hosting policy requires that a plugin and all its companion files (except the config file) are installed to the same folder. This was not the case in the past.

You are right about it.

Users which are facing problems with their legacy plugins should at first try to copy all files and folders belonging to the plugin in question to %USERPROFILE%\AppData\Local\Notepad++\plugins\myAwesomePlugin. If this doesn’t help they should contact the author of the plugin to request an update that adopts the new plugin hosting model of Notepad++.

Yes, indeed.

The new plugin loading way is not only KISS (keep it simple, stupid), but also provide a cleaner way to make plugin authors’ life easier (though it’s not the case for some lagacy plugin authors) - all the extra data files/binairies/libraries can be aside of plugin entry (DLL), and use them with the relative path.

all the extra data files/binairies/libraries can be aside of plugin entry (DLL), and use them with the relative path

That’s right but currently there exists no easy method to query the plugin DLL path. Plugin devs have to deal with the DLL module handle and GetModuleFileName API (which is poorly designed and whose documentation is difficult to understand). Have you already thought about my suggestion here? Another possible unique ID instead of the module handle would be the plugin DLL name.

It will be useful to implement command Open plugins folder somewhere in the Notepad++ menu (for example in the ? menu or just above Plugins Admin in Plugins menu) that will open the Notepad++ plugins install folder in Windows Explorer.
This way the users can quickly find where their plugins are located no matter if Notepad++ is portable or installed or whatever. It will also make troubleshooting problems related to plugins location easier.

It will be useful to implement command Open plugins folder somewhere in the Notepad++ menu (for example in the ? menu or just above Plugins Admin in Plugins menu) that will open the Notepad++ plugins install folder in Windows Explorer.

It’s a nice to have feature. But currently I have the other priorities to treat.

the condition if (hasPlugins() || enablePluginAdmin) was removed in @pnedev 's commit, so there’s a slight change in the default behaviour:

before, if plugins admin was disabled or gup not present and no plugins were installed, the plugins menu would disappear completely.
(for example in cases where all default plugins were removed, or are in a wrong path structure of a version prior to 7.6.x but using a newer notepad++ binary on top ot this folder structure)

now the plugins menu is always present.
so even if there are no plugins installed (all default plugins removed) and plugins admin is not active or present, users are still able to reach the new “open plugins folder…” menu entry to find and reach the plugins folder with a single click of a mouse button, to add any desired plugins manually.

And where do I put my “Squirrel Highlighter plugin”? (LUSquirrel.xml)
I used to put it in “C:\Program Files (x86)\Notepad ++\plugins\Config\ LUSquirrel.xml” and it worked.
Now, put it where you put it, it does not appear in Notepad ++

In my country there is a clear sentence: “If something works, do not change it”.

then copy it to C:\Program Files (x86)\Notepad++\autoCompletion\.
(C:\Program Files (x86) is an example and will depend on your notepad++ installation path)

if your LUSquirrel.xml file begins with:

<NotepadPlus>
<UserLang name="..." ext="" udlVersion="2.1">
...

then copy it to %AppData%\Notepad++\userDefineLangs\.

note: if your notepad++ is not a default installation, or a portable version, we would need your debug info from the notepad++ menu ? > información de reparación... > copy debug info into clipboard to tell you the corresponding paths.