Extension talk:Flex Diagrams

When I open an existing Drawio graph and edit it for the first time during a session, then click the in-graph save button and then the page save button, the page saves and displays as expected. When I do a second edit to the same diagram, the post-save view shows the old version of the diagram.

• This is the same on three wikis, two in shared hosting and one on our own linux server.
• I tried this in Firefox and Edge, same behaviour. I stripped a test wiki down to the minimum with no additional extensions beyond FlexDiagram, same problem.
• A refresh or ctrl-shift refresh don't fix the issue. Running update.php and re-loading the page displays the post-second-edit diagram.
• cache is off:

$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = [];

• I tried this with extension MagicNoCache, it doesn't fix the problem.
• version: 0.5.2 (c6271e2) 01:28, 10 May 2024
• installed via git pull and git checkout REL1_41
• PHP is 7.4.28 on my clean test system, and I realize that's outdated and am now trying to get that updated; however, the two other wikis with the same problem both use 8.1.27 so I don't really think that's the problem

This is the same as the "Can't save" discussion, no? (Though expressed more clearly.)

Definitely part of the same troubleshooting for me, you are right. That other discussion had diverged from the original problem of an ongoing hourglass and then the error. I also don't get the blank page from which I can't get into the editor any more. So the previous one was getting very muddled and I decided to start fresh with what is actually still a problem. I figured that would also make it easier for anyone else with the same, remaining problem to find this. And, for that problem I wasn't able to replicate it on my other install. For this one, the same problem happens on three different installs in two different environments.

I have been running this on one wiki where it works great, and just installed it on another one where I can't save Drawios. Both run php 8.1.27 , FlexDiagrams 0.5.2 (2d8d4a3) 02:28, 2024 April 22, MW1.41.1. If I click the save button on the editor, initially nothing happens. When I click it again, the spinny disk comes up but it stays there (it's a small one, when the save works right on the initial wiki it's a bigger spinny disk). If I click "save page" at the bottom it ask me if I really want to leave, it clearly doesn't finish the editor safe. If I say yes it saves a page that then doesn't let me back into the editor, I have to delete the page and start over. I enabled debugging and found the following errors:

Failed to register/update a ServiceWorker for scope ‘https://embed.diagrams.net/’: Storage access is restricted in this context due to user settings or private browsing mode.  

and

Uncaught (in promise) DOMException: The operation is insecure.
   main https://embed.diagrams.net/js/app.min.js:12979
   checkAllLoaded https://embed.diagrams.net/?embed=1&spin=1&proto=json:247
   <anonymous> https://embed.diagrams.net/?embed=1&spin=1&proto=json:458

and

 Source map error: request failed with status 404
Resource URL: https://embed.diagrams.net/js/app.min.js
Source Map URL: purify.min.js.map 

These show up on both wikis, though. Actually, the one that works gets one more line of error under uncaught promise:

EventListener.handleEvent* https://embed.diagrams.net/?embed=1&spin=1&proto=json:455

Any suggestions how I would troubleshoot that?

Hi! Which browser(s) does this occur with? And do you have any special privacy setting for those browser(s)?

Nothing in the console, even with full debugging. Firefox with ublock disabled; tried edge with no blockers, same thing. And it wasn't working with that yesterday, but now it does. Or did. Once or twice. Back to troubleshooting...

Still having the problem. Found out one additional thing. When I try to edit a page that already exists I don't get the "asking you to confirm that you want to leave" error, but the page doesn't actually get saved, either. Found a few messages that aren't necessarily errors:

[ActionFactory] editdiagram is being set in configuration rather than CORE_ACTIONS
[ActionFactory] editdiagram is being set in configuration rather than CORE_ACTIONS
[ActionFactory] Overriding normal handler for editdiagram
[ActionFactory] editdiagram is being set in configuration rather than CORE_ACTIONS
[ActionFactory] Overriding normal handler for editdiagram

That's strange; I don't know. Unrelated question: are you able to save diagrams of a type other than Drawio/diagrams.net on that wiki?

I just added a mermaid diagram, and I was able to add it and then edit it later.

Alright, that's good to know. So, as for Drawio, sometimes it does work? In both browsers you tried?

It must have worked at least once, since I have one page that has a diagram in it. Tonight I tried in firefox and was able to make a new page that has a diagram in it, and save that, but when I try to edit the changes are not saved. So, for this the data isn't updated, but what is there is shown right. Then I tried in edge and got the "changes you made may not be saved". It actually shows the "text" data for the form, and if I copy-paste that text into a different wiki with working Drawio, it displays it as a diagram. If I then click the "edit diagram" tab again for a page where the diagram won't show, the editor doesn't show. For this it's almost like it can't reach the service but the data is stored right. Having said that, I have had the problem that happens in Edge tonight on Firefox over the last few days, so I don't really think this is necessarily a browser difference.

I played with this some more tonight... It appears that the new text code actually gets saved, just the image isn't being updated. When I make an edit and save, the same image stays. When I paste the text to a different wiki where drawio works, it corresponds to the edited version. Also, if I move the page to a different page name, the image on that moved page is then the one I saved. Weird.

Oh, interesting - it sounds like your server is possibly just caching Drawio diagrams too aggressively. There may be some web server configuration you can change to fix this; I don't know.

Interesting thought. I have been working with support from my shared host for the last week or so because crontab is re-running old jobs that have long been deleted and/or updated. Your suggestion makes me wonder if the two might be related. Flexforms and DrawIO work fine on a different account with the same host that doesn't have crontab craziness. I have sent that to support, we'll see if that gets me anywhere.

I have moved the wiki to be hosted on our own server, and still get the problem with saving. I now wonder if this has to do with one of the other extensions that are installed.

I looked into this a little too - I had forgotten this, but when displaying Mermaid diagrams, the Flex Diagrams code sets $wgResourceLoaderDebug to true, to stop caching of their display - see here. If possible, could you try adding that same code to the handling of Drawio diagrams, right above it, to see if that improves the situation?

I changed line 61 from

global $wgOut;

to

global $wgOut, $wgResourceLoaderDebug;

It didn't fix the problem. Was it meant to fix the problem or to provide more info about it? I don't know what adding $wgResourceLoaderDebug is supposed to do. Also, that class's description says it's for the parser function, but this is a problem even on the drawio: namespace page.

Okay - there are various errors here, but it doesn't really matter because it turns out that turning on debug mode is being done to get the JavaScript to load correctly, not to disable caching. So I'm back to not knowing - clearly it's a caching issue, but I don't know how to fix it.

When displaying 2 or more diagrams in a single page, the extension says:

Due to current limitations, #display_diagram can only be called once per page on any BPMN or Gantt diagram.

Clearly the extension author knows this so the purpose of this topic is to let the author know that it is an essential capability to provide for many practical applications. Thank you!

Hi Yaron, Just checking in on this. Is being able to have more than one diagram in a single article on your radar?

Is there going to be a future state where this issue is resolved? I would love to be able to display multiple DrawIO diagrams on one page, currently we are splitting the content across multiple pages to get around this issue, which is fine, but somewhat frustrating.

+1

Unfortunately, this is what's holding this extension back and quite a lot. Hopefully it's somewhere in their radar.

Would love the functionality to have more than one diagram per page displayed - any chance of implementation?

There is an error with using the Mermaid feature.

An error has occurred”Syntax error in graph , mermaid version 8.13.4"

Found out, I used the new syntax of the Mermaid tutorial, sorry.

Submitted a patch to update Mermaid to 10.2.1

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlexDiagrams/+/926418

Can you update for REL1_39 and REL1_40 branches?

I get the error "Syntax error in text. mermaid version 10.2.1" with version 0.5.2 on MW 1.39.

I installed on mediawiki 1.40 and when I save diagrams they simply don't save sometimes. Also, when I revert in mediawiki to an older version, the same version renders

Sorry, I didn't understand the second sentence.

At present, displayed diagrams are rendered in a one-size-fits-all way. This The ability to tailor the displayed diagram is an essential capability to provide for many practical applications. Thank you!

Do you mean for #display_diagram?

Yes

I can understand wanting to set the height and width (you can already do that with a wrapper div around the #display_diagram call), but when would it make sense to do a zoom in and not show the entire thing when the diagram is first displayed? MediaWiki doesn't provide an easy way to, for example, zoom in by default on one part when displaying an image.

It would make sense in a page that is dedicated to discussing just a specific section of a large diagram, like a help page. Without this feature, editors are forced to take screnshots of the zoomed in sections and upload them as stand-alone image files and repeat that process when changes are made to to the main diagram. But if the goal is to have a diagraming system that functions entirely "in wiki" and does not require editors to have to download/capture specific content and then re-upload it back to the wiki ever time something changes, then I think this would be a key part of that goal. Is that the goal? to have a diagramming system that functions entirely within the wiki? If not, then I could see not wanting to add the capability.

Maybe something like the width, max-width and height options that DrawioEditor uses? Maybe in addition with a float option so you can right-align it.

Also thanks for the div tip! I hadn't thought of that but it works perfectly for my use case.

@Revansx - that's a great question, I'll have to think about that. :) I can see some benefits of zooming. On the other hand, it feels strange - I haven't seen a default zoom on anything other than a map. Plus, any time the diagram gets edited, the zoom settings may have to change. Of course, that's easier to do than uploading a new screenshot. On the other hand, a screenshot may require less frequent changes.

@Lonaowna - given the "div" option, are any of these parameters still useful?

The "div" option seems to enable all of my layout wishes. However, it does not really work well with VisualEditor (the div and the contents are not visible at all). The bare #display_diagram is visible, so that's better (although I haven't found a way to insert a #display_diagram in VisualEditor yet).

Yaron, thanks for agreeing to think about it.

Regarding the need to update zoom and position data when the full diagram is edited..

yes.. but that would be a simple "in-wiki" edit, which I'm assuming is much preferable to an "out of wiki" activity requiring page editors to go and take new screenshots and re-uploading them over the old ones, etc...

Again, I am basing this on the assumption that fully "in-wiki" solutions are preferable to "out-of-wiki" solutions.

..And your "maps" example is spot-on. We need default zoom and position capabilities for the exact same reason that map users do. totally!

As for not seeing any precedents other than maps.. it is because people are using visio and screenshots and Word and there is no real wide-spread use of BPMN and GANTT diagrams that are fully integrated into a single "CMS" . You have the opportunity to set the bar here if you have the vision and the will. :-)

Well, maps are different because the world map represents a pre-defined data set, as opposed to a diagram where everything is real data.

Well, if you’re looking for a distinction to build a case around, I’m sure we can each find as many we wish. At the end of the day, the question is whether or not the zoom and position features are valuable to users and that’s just a good’ol case of actually having real-world experience in trying to use these things (processes) in real-world applications. I would be very interested to know to what extent you are using these tools on the business side of your own world. That really does have an effect on your point of view.

In the meantime, i accept that you’re not supportive of this capability and I will continue to be grateful for what you have provided. As always, thank you for letting me make the request and the time you have spent considering it.

I haven't used Flex Diagrams at all yet (other than testing), though I hope to make real use of it at some point. Thanks for your feedback.

wrapping #display_diagram within a div that has its height set to 1000px doesn't appear to make the diagram adjust its zoom level accordingly

For some reason there's a #canvas div drapping #display_diagram with a fixed height of 40em? I had to set it to 100% to allow the wrapper div's fixed height to take effect.

We have MediaWiki running on Apache but accessed via an IIS reverse proxy. The extension works perfectly when accessed directly however when accessed via the reverse proxy throws an ASP.NET application error.

I was able to get the diagrams to render by updating the value of $wgServer in LocalSettings.php to the URL that the site is being re-written to however editing via the re-written URL still throws an error and then display and edit at the direct URL no longer work.

Turns out the issue was the : in the URL - IIS by default does not allow this in the path - once I added the below to my config file and update my $wgServer to the IIS bound URL it all worked

<system.web>

<httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,\,?" />

</system.web>

Visual editor has an "insert" menu, where image, template, table etc. can be selected. Would be great if "diagram" would show up there in case Flex Diagrams is installed. AFAIK this can be done, see https://www.mediawiki.org/wiki/VisualEditor/Gadgets#Triggering_a_command_using_a_toolbar_tool

I draw a diagram using Flex diagrams

1. I want to set the diagram to a thumb nail at right side
2. I want to set the width of the diagram to 300px in main text.

Is there any methods. My mediawiki version is 1.36.1

I don't think so, unfortunately; it would be nice for #display_diagrams to support "height=" and "width=" parameters.

I would very much welcome parameters for height and width.

I did some more work on generating mermaid code from Cargo for an org chart. This generated ~1500 lines of code. I ran into two problems. Initially I got an error that there was too much text (sorry I didn't take it down verbatim). I shortened the annotations in my links (which don't show up anyway, btw), and that error went away and I was able to save the mermaid: page. But when I now try to open it from a page with {{#display_diagram:Mermaid:...}} I get a "Syntax error in graph" (even though the page works on the mermaid:... page). I wonder if they use different size string variables or something. So, there are size limitations to this, which is reasonable, the huge graphs aren't very easy on the eyes anyway. But: it would be great to know what the limitations actually are. And I still think it would be awesome if this was able to take query output from Cargo directly - I now have a setup where I manually copy-paste it from Cargo output to the Mermaid page.

I didn't know there were problems with handling overly-large text, with either Flex Diagrams or the Mermaid library itself. What was the initial error message? That would be helpful to know - especially to know whether the error comes from FD or Mermaid.

The error is "Maximum text size in diagram exceeded"; if I paste it into https://mermaid.live I get the same error, so that's Mermaid not FlexDiagrams. A somewhat smaller version of the code will display fine in the mermaid:... page, but not when called with {{#display_diagram:Mermaid:...}}. That one just gives a "syntax error in graph" with that bomb icon, which is what it would do if code was cut in mid command, so I wonder if there is a variable size problem. Debug log near mention of mermaid is

[objectcache] fetchOrRegenerate(global:SqlBlobStore-blob:intmedmw-mw_:tt%3A37700): miss, new value computed
[ContentHandler] Registered handler for flexdiagrams-mermaid: FDMermaidContentHandler
[objectcache] fetchOrRegenerate(intmedmw-mw_:preprocess-hash:880fce3f791fe26f617801db0e5458476e9e8ce4:0): miss, new value computed

Sorry, I missed this before. The caching failure seems unrelated to the syntax error, but I don't know anything beyond that. This may be outside of the ability of the Flex Diagrams code to fix.

So whatever variable type is used for the {{#display_diagram tag is not smaller than the one on the mermaid:... page?

I don't think so... it's the same code that handles display in both places, if I remember correctly.