Plugins loading way has been changed in Notepad++ 7.6 (and upper versions)
-
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++). - go to
%PROGRAMDATA%\Notepad++\plugins\
to create myAwesomePlugin folder. - 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/
Before doing your PR, please test locally listing/installation/removal/update your plugins, by following the instructions in the link below:
https://notepad-plus-plus.org/features/plugin-admin.htmlAny question or request goes here:
https://notepad-plus-plus.org/community/topic/16566/support-for-plugins-admin-npppluginlistSorry for the inconvenience, but all the changes It’s for a good cause. :)
- Find the name of plugin you want to migrate in
-
@donho said:
That’s it. Restart Notepad++ and you get your beloved plugins back.
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++. -
@donho said:
In future release version 7.6
What about moving to version 8.0 because we have a new major feature.
-
After some testing with legacy plugins I want to share my experiences.
I took an official 32 bit Notepad++ v7.5.9 local installation with various legacy plugins and replaced
notepad++.exe
with the AppVeyor 32 bit debug build of commit e61fe03 andGUP.exe
with the testing binary of 2018-11-02 and tried to get them running.- 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
.
These are the plugins I’ve tested
AutoCodepage.dll
AutoEolFormat.dll
CodeAlignmentNpp.dll
ColorPicker.dll
ComparePlugin.dll
CSScriptNpp.dll
CustomizeToolbar.dll
CustomLineNumbers.dll
Explorer.dll
FallingBricks.dll
HexEditor.dll
LanguageHelp.dll
MarkdownViewerPlusPlus.dll
NavigateTo.dll
NppBookmarkManager.dll
NppCalc.dll
NppColumnSort.dll
NppCrypt.dll
NppEventExec.dll
NppExec.dll
NppFTP.dll
NppHorizontalRuler.dll
NppMenuSearch.dll
NppRegEx.dll
NppTextFX.dll
NppToolBucket.dll
OpenSelection.dll
PoorMansTSqlFormatterNppPlugin.dll
ReloadButton.dll
SelectQuotedText.dll
SpeechPlugin.dll
SQL.dll
XmlTools.dllDetails 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. - For every plugin there has to be created a folder
-
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.
-
@donho said:
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.
-
Regarding XmlTools there was already a commit (https://github.com/morbac/xmltools/commit/3b266ec4933bab03dfd84b70f905e6ff69f931c2) to overcome this limitation that companion dlls are search by the N++.exe folder, but that seems not to work.
-
How does this work for people using Notepad++ Portable? Does everything just reside in the Notepad++ directory?
-
@ImSpecial said:
How does this work for people using Notepad++ Portable? Does everything just reside in the Notepad++ directory?
Yes, it should be like this.
-
@donho ,
It will be useful to implement command
Open plugins folder
somewhere in the Notepad++ menu (for example in the?
menu or just abovePlugins Admin
inPlugins
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.Tell me what you think.
-
@pnedev said:
It will be useful to implement command
Open plugins folder
somewhere in the Notepad++ menu (for example in the?
menu or just abovePlugins Admin
inPlugins
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.
-
@donho ,
I can implement it but I’m also a bit busy these days. Will do it when I find the time.
I will keep you posted. -
@donho ,
Done.
Here is the feature request: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/5224
and here is the pull request: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/5225 . -
-
a little side note (also positive), if it is of interest for others:
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”.
-
hola y bienvenido a la notepad++ community, @Zoilo-Lagos-Lopez
on notepad++ 7.6.6, if your
LUSquirrel.xml
file begins with:<?xml version="1.0" encoding="Windows-1252" ?> <NotepadPlus> <AutoComplete language="...">
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.saludos.