Rendering sometimes works sometimes fails

[finjulhich]

httpd-2.4.41-12 php-fpm-7.3.15-1 mediawiki-1.32.4-1 PlantUML version 1.2020.00 (Sat Jan 11 12:30:53 GMT 2020) gchrome 79.0.3945.130

Sometimes, my httpd/php/mediawiki + plantuml generates rendering correctly, as it appears when I browse the page, and right after editing UML, or reloading the page, sometimes my browser renders this, as observed by chrome F12:

<object 
  class="plantuml" 
  type="image/svg+xml" 
  data="/wiki/images/uml-e6c4dc4987dc8b0ce38b7b8e14db172d-9e9d73063f2edcfa17ff371ad768db47.svg" 
  svg="" 
  xmlns="http://www.w3.org/2000/svg" 
  xmlns:xlink="http://www.w3.org/1999/xlink" 
  contentscripttype="application/ecmascript" 
  contentstyletype="te>Your browser has no SVG support. Please install <a href=" http:="" www.adobe.com="" viewer="" install="" "="">Adobe SVG Viewer plugin (for Internet Explorer) or use <a href="http://www.getfirefox.com/">Firefox</a>, <a href="http://www.opera.com/">Opera</a> or <a href="http://www.apple.com/safari/download/">Safari</a> instead.
</object>

Any ideas why it works sometimes and not others.

[WolfgangFahl]

Thx for the question. Recent Mediawiki versions have changed the image handling which might effect the rendering behavior. This is one of the reasons for the approach shown in

• http://wiki.bitplan.com/index.php/Diagrams
• http://diagrams.bitplan.com/
• https://www.mediawiki.org/wiki/Extension:Diagrams

The object embedding is needed since MediaWiki itself does not support inline svg see https://www.mediawiki.org/wiki/Inline_SVG_use

As long as the linked svg exists - in your example /wiki/images/uml-e6c4dc4987dc8b0ce38b7b8e14db172d-9e9d73063f2edcfa17ff371ad768db47.svg

you should be fine and my guess would be there is a problem with the caching handling and a page refresh in the chrome browser might do. Also testing with a different browser might give you some clue.

If the svg does not exist it would be a reason to look into the plantuml extension itself more extensively.

[finjulhich]

Actually, looking at directory /var/www/wiki/images/, I only see

0/         2/         4/         6/         8/         a/         b/         d/         e/         graphviz/  lockdir/   README     thumb/     
1/         3/         5/         7/         9/         archive/   c/         deleted/   f/         .htaccess  math/      temp/      tmp/      

so there are no uml-*.svg at all.

Also I see those errors in /var/log/httpd/error_log

[SimonVanacco]

I have observed this behavior has well on my MediaWiki instance, any idea to make the "Your browser has no SVG support." message never appear ?

[WolfgangFahl]

@SimonVanacco - thx for reporting this. What MediaWiki version are you using?

[finjulhich]

mediawiki-1.32.6-1.fc31.noarch

[WolfgangFahl]

@finjulhich for recent Mediawiki there have been breaking changes and I personally do not intend to fix the old PlantUML to fight this situation. The problem also hits the Graphviz extension. https://phabricator.wikimedia.org/T226616 now has a proposal for the fix. So there are two options: you could clone the old PlantUML try applying the proposed fix and make this a Pull request or you could migrate to the http://wiki.bitplan.com/index.php/Diagrams solution which supports more recent MediaWikis.

[RaphaelUnique]

after some investigations when the files are not displayed, getImage (PlantUML.body.php) is called 2 times:

1. with the correct title of the page
2. with a wrong title: Sp\xc3\xa9cial:Badtitle/dummy title for API calls set in api.php

the result filename is composed of the hash of the title and the content, so there is 2 differents names , and the second is wrong.

as a workaround , you just a to assign a static content in $title: //$title=$this->getPageTitle($parser); $title=" ";

after that, all the files are generated and displayed correctly