Embed mode: using first-party plugins served from non-/ URL

[bollwyvl]

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Is your feature request related to a problem? Please describe.

Thanks so much for this great tool!

The plugin urls listed in App.pluginRegistry all have a leading /. In embed mode, plugins specified via the p URL param fail to load if index.html is served from anywhere other than the / of a host. base looked compelling, but doesn't appear to change this behavior.

I can get the first-party plugins to load with the configure action after the fact with a hand-made URL, but these pop the ARE YOU SURE?!? dialog, which isn't very friendly.

Describe the solution you'd like

Copying the logic for detecting first-party plugins and have it take effect when loading plugins specified with p with loadPlugins would probably do the trick.

If the plugins in the registry will always start with /, this could be even simpler:

diff --git a/src/main/webapp/js/diagramly/App.js b/src/main/webapp/js/diagramly/App.js
index daa28a3d..8130152c 100644
--- a/src/main/webapp/js/diagramly/App.js
+++ b/src/main/webapp/js/diagramly/App.js
@@ -1131,7 +1131,7 @@ App.loadPlugins = function(plugins, useInclude)
                {
                        try
                        {
-                               var url = App.pluginRegistry[plugins[i]];
+                               var url = PLUGINS_BASE_PATH + App.pluginRegistry[plugins[i]];
 
                                if (url != null)
                                {

With the above modification, hammering a nasty setInterval to update PLUGIN_BASE_PATH in the iframe.onload works, but seems like bad form. Ideally, there would be a way to set PLUGINS_BASE_PATH via url param, e.g. pbp=., as otherwise I haven't yet needed to modify any files... but will eventually have to munge PreLoad.js or index.html, I'm sure, so can certainly work with just the above!

Describe alternatives you've considered

• The electron app appears to blanket prepend a .. This could work (though it also appears to have PLUGINS_BASE_PATH)
• stripping the / off the entries works locally, but there's lots of code that's looking for that /, so this is probably a bad idea.
• being able to set this via the configure action would work... but seems to be occurring far too late in the lifecycle.

Additional context

I am encountering this in the context of adapting jupyterlab-drawio for embed mode. It's really working quite well, now, without any modifications, which makes it far easier to stay up-to-date.

On an even more experimental branch, I've done an XML embedding inside an .ipynb file, which works great (e.g. one can use a plotting library to generate (preferably) an SVG in the notebook side of the screen, then drag it right into the Drawio. What I really want, though, is a way to embed a "live" object (either a markdown cell or an output) into the mx model which will update whenever the source/output changes, and feel like I need to get my baseline plugin situation sorted before starting that.

Another plugin i'd like to build (or see built!), in the vein of the webcola plugin, is an elkjs layout which excels particularly at laying out diagrams with ports.

Somewhat off-topic: I've also been exploring integration of the PDF export server, and even embedding the XML into the final PDF as an attachment. Right now I've been tinkering on that with the backend language (python), and one needs to use the "right" PDF viewer to pull the attachment back out, but am trying to get this to work in the browser automatically. pdfjs isn't lightweight, but it seems to be the only game in town.

Thanks again!

[alderg]

Thanks for the report. We will prefix the URL with PLUGINS_BASE_PATH in the next release. Unfortunately, we cannot use a URL parameter for security reasons.

[bollwyvl]

That will be great. It seems reasonable to not allow that dynamically, while in an embedding use case, it will be easier to patch one of the config files rather than app.min.js, which is what I'd settled on in the meantime.