Extension talk:Diagrams

Diagrams are not displayed when exporting to PDF or ODT using the Collection extension. Is this supposed to work?

Don't think so. Diagrams are displayed client-side with JavaScript; and you can export to PDF only what is rendered server-side. This is the gotcha with fancy easy-to-develop extensions that make external JavaScript libraties available in MediaWiki.
Alexander Mashin ^talk 02:40, 19 March 2024 (UTC)

That's true for Mermaid or other client-side rendered diagrams, but we should be able to make it possible to include server-side rendered diagrams in other output such as PDF. I've not looked into why it's not already working.

I am referring specifically to diagrams produced with PlantUML that are rendered on the server and saved in the images/diagrams folder in PNG format. I am not familiar with the internals, but I notice that in the HTML, the <img> tag is used, whereas for classic MediaWiki images, the <figure> tag is utilized.

sorry, I mean as a wrapper element.

Hi there, we're trying to run the "graph" format of Semantic Results Format, which evidently requires Diagrams to function. We just plugged in the default example query which for us looks like:

{{#ask:[[Category:People]]
	|?Teacherof
	|?Studentof
	|format=graph
	|graphcolor=yes
	|graphlink=yes
	|graphname=TeacherStudentRelationships
	|graphlegend=yes
	|graphlabel=no
	|graphsize=10,100
	|rankdir=TB 
}}

We are getting the following error when trying to save the page:

[ba1052b0702986c0a93cde15] /index.php?action=submit&title=User:Jeremi Error from line 160 of /var/www/html/extensions/Diagrams/includes/Diagrams.php: Call to undefined method MediaWiki\Shell\CommandFactory::createBoxed()

Backtrace:

#0 /var/www/html/extensions/Diagrams/includes/Diagrams.php(114): MediaWiki\Extension\Diagrams\Diagrams->runCommand()
#1 /var/www/html/extensions/Diagrams/includes/Hooks.php(54): MediaWiki\Extension\Diagrams\Diagrams->renderLocally()
#2 /var/www/html/includes/parser/Parser.php(3922): MediaWiki\Extension\Diagrams\Hooks::MediaWiki\Extension\Diagrams\{closure}()
#3 /var/www/html/includes/parser/PPFrame_Hash.php(340): Parser->extensionSubstitution()
#4 /var/www/html/includes/parser/Parser.php(2887): PPFrame_Hash->expand()
#5 /var/www/html/includes/parser/Parser.php(1556): Parser->replaceVariables()
#6 /var/www/html/includes/parser/Parser.php(850): Parser->internalParse()
#7 /var/www/html/extensions/SemanticResultFormats/src/Graph/GraphPrinter.php(183): Parser->recursiveTagParse()
#8 /var/www/html/extensions/SemanticMediaWiki/src/Query/ResultPrinters/ResultPrinter.php(341): SRF\Graph\GraphPrinter->getResultText()
#9 /var/www/html/extensions/SemanticMediaWiki/src/Query/ResultPrinters/ResultPrinter.php(306): SMW\Query\ResultPrinters\ResultPrinter->buildResult()
#10 /var/www/html/extensions/SemanticMediaWiki/includes/query/SMW_QueryProcessor.php(348): SMW\Query\ResultPrinters\ResultPrinter->getResult()
#11 /var/www/html/extensions/SemanticMediaWiki/src/ParserFunctions/AskParserFunction.php(361): SMWQueryProcessor::getResultFromQuery()
#12 /var/www/html/extensions/SemanticMediaWiki/src/ParserFunctions/AskParserFunction.php(196): SMW\ParserFunctions\AskParserFunction->doFetchResultsFromFunctionParameters()
#13 /var/www/html/extensions/SemanticMediaWiki/src/ParserFunctionFactory.php(402): SMW\ParserFunctions\AskParserFunction->parse()
#14 /var/www/html/includes/parser/Parser.php(3340): SMW\ParserFunctionFactory->SMW\{closure}()
#15 /var/www/html/includes/parser/Parser.php(3047): Parser->callParserFunction()
#16 /var/www/html/includes/parser/PPFrame_Hash.php(263): Parser->braceSubstitution()
#17 /var/www/html/includes/parser/Parser.php(2887): PPFrame_Hash->expand()
#18 /var/www/html/includes/parser/Parser.php(1556): Parser->replaceVariables()
#19 /var/www/html/includes/parser/Parser.php(651): Parser->internalParse()
#20 /var/www/html/includes/content/WikitextContent.php(374): Parser->parse()
#21 /var/www/html/includes/content/AbstractContent.php(590): WikitextContent->fillParserOutput()
#22 /var/www/html/includes/Revision/RenderedRevision.php(263): AbstractContent->getParserOutput()
#23 /var/www/html/includes/Revision/RenderedRevision.php(235): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
#24 /var/www/html/includes/Revision/RevisionRenderer.php(215): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
#25 /var/www/html/includes/Revision/RevisionRenderer.php(152): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
#26 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
#27 /var/www/html/includes/Revision/RenderedRevision.php(197): call_user_func()
#28 /var/www/html/includes/Storage/DerivedPageDataUpdater.php(1315): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
#29 [internal function]: MediaWiki\Storage\DerivedPageDataUpdater->getCanonicalParserOutput()
#30 /var/www/html/includes/edit/PreparedEdit.php(104): call_user_func()
#31 /var/www/html/includes/edit/PreparedEdit.php(119): MediaWiki\Edit\PreparedEdit->getOutput()
#32 /var/www/html/includes/Storage/DerivedPageDataUpdater.php(1293): MediaWiki\Edit\PreparedEdit->__get()
#33 /var/www/html/includes/page/WikiPage.php(2117): MediaWiki\Storage\DerivedPageDataUpdater->getPreparedEdit()
#34 /var/www/html/extensions/SpamBlacklist/includes/SpamBlacklistHooks.php(34): WikiPage->prepareContentForEdit()
#35 /var/www/html/includes/HookContainer/HookContainer.php(329): SpamBlacklistHooks::filterMergedContent()
#36 /var/www/html/includes/HookContainer/HookContainer.php(132): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#37 /var/www/html/includes/HookContainer/HookRunner.php(1529): MediaWiki\HookContainer\HookContainer->run()
#38 /var/www/html/includes/EditPage.php(1906): MediaWiki\HookContainer\HookRunner->onEditFilterMergedContent()
#39 /var/www/html/includes/EditPage.php(2365): EditPage->runPostMergeFilters()
#40 /var/www/html/includes/EditPage.php(1726): EditPage->internalAttemptSave()
#41 /var/www/html/includes/EditPage.php(680): EditPage->attemptSave()
#42 /var/www/html/includes/actions/EditAction.php(71): EditPage->edit()
#43 /var/www/html/includes/actions/SubmitAction.php(38): EditAction->show()
#44 /var/www/html/includes/MediaWiki.php(532): SubmitAction->show()
#45 /var/www/html/includes/MediaWiki.php(313): MediaWiki->performAction()
#46 /var/www/html/includes/MediaWiki.php(945): MediaWiki->performRequest()
#47 /var/www/html/includes/MediaWiki.php(548): MediaWiki->main()
#48 /var/www/html/index.php(53): MediaWiki->run()
#49 /var/www/html/index.php(46): wfIndexMain()
#50 {main}

Any information or clues? Thank you so much!

Jeremi Plazas (talk) 17:38, 28 February 2024 (UTC)

I am using this extension to create graphviz diagrams with clickable URLs.

After creation of the image, everything works fine. But after returing to the page on the next day, the automatically created imagemap has vanished from the page and the image is not clickable any more. It can be restored by doing some major edits to the page, though the same issue will occur again later on.

When renaming the wiki page, the URLs in the graphic stop working immediately.

What is going on here and how do I avoid this?

This is Mediawiki 1.39.3, Diagrams 0.9.4, graphviz 2.43.0.

Sample code:

<graphviz caption="Supportprozess" format="svg">
digraph procsupp {
node [shape=box,style=filled,fillcolor=cornflowerblue];
 
Entwicklungsprozess [URL="[[I2023/Entwicklungsprozess]]",fillcolor=yellow];
xx [URL="[[xx]]"];  

Entwicklungsprozess -> xx
} 
</graphviz>

Update

To me it looks like that the imagemap is not recreated correctly after the page has been deleted from the Parser Cache:

If I increase $wgParserCacheExpireTime, the previously observed problem on the next day vanishes.

With the standard $wgParserCacheType, the imagemap vanishes on a restart of the wiki server. By making the Parser Cache persistant by setting $wgParserCacheType = CACHE_DB, the imagemaps will survive a server restart.

I also noticed that image maps will not be available when the page content is included using a {{:xxxx}} construct. I assume this is due to the same problem of Diagrams not parsed correctly when done in the background instead of after an active edit of the page.

@Omerzu: It sounds like this is the issue reported at https://github.com/samwilson/diagrams-extension/issues/76 for which I've just made a fix. Sorry it's taken so long to sort out!

Yes, indeed, it is. Thanks for solving it!

Hi

I have a similar issue. If I make a graphviz diagram with links the svg and the cmapx file are created in /images/diagrams. but if I use <uml> the cmapx file is not created.

Are Links in <uml> diagrams suported or is this still an open topic? If so I would have to rewrite all uml diagrams with links to graphviz.

MW Version 1.41

img_auth.php rejects to serve diagram outputs under images/. Is there any solution besides disabling img_auth.php? Or is the output location configurable, like Extension:Widgets does?

Sorry, I've only just seen this post! I've opened GH#61 to track this, and will try to get it fixed soon.

This can be fixed with a configuration change, now detailed in the installation instructions.

I did set up this extension, and i installed graphwiz, mscgen and plantuml, and it works beautifully for these three languages. before i installed the respective binaries, there was an error message telling me that the binary was not found, which was helpful.

unfortunately i dont have any luck with mermaid. the images simply do not render. where the image should be, there is a hidden div containing the mermaid source, so i can see that the tag is read correctly and interpreted, as having the source in a hidden element (which will then be read and replaced by javascript) is the normal way. problem is, the actual rendering of the mermaid diagram never takes place, so that no image is generated, and no error either.

can this be because the computer the webserver is running on is behind a proxy? shouldnt it work anyways because the extension ships its own mermaid files?

Hello. I try to render a simple uml diagram, but get an error:

Diagrams error (with plantuml command): /bin/bash: line 1: plantuml: 
command not found

I've downloaded latest archive, extracted it and added line into LocalSettings.php.

Am I missing anything? Should I install any other additional software?

Well, one should install plantuml and graphviz as separate packages. Diagrams is just a wrapper for these tools in mediawiki. Now everything works fine.

hi!, i installed the extension, but per dafault render the diagrams (in this case grapviz) are represented in png exist a global setting for change the type of file for example a svg?

@Alex Mashin: you added a link to Extension:External Data/Local_programs#Complex_example, but it doeesn't look like that's very related to Diagrams. Also, the section ID doesn't exist.

I have updated the section title. It contains information about External Data use case that allows to draw diagrams.
Alexander Mashin ^talk 02:37, 18 June 2022 (UTC)

Great, thanks!

The extension.json states 1.32 is needed. I'd like to run the extension with the current 1.31.7 LTS version. Is there anything that prevents this? I tried simply setting the extension.json requirement lower ...

Is there any documentation about which features of the PlantUML extension are not supported by the Diagrams extension?

You might want to ask this at https://gitter.im/diagrams-service/community