SL Wiki: Please fix SVG support (old issue reported on Jira)
tracked
Gwyneth Llewelyn
Hi there!
SVG uploads have been broken on the SL Wiki since
September 2022
. This was reported on the Jira [the link is to the archived Jira].To reproduce, all that is needed is to search for SVGs on the file library. Almost all (and all from September 2022 onwards) will appear to be broken.
Here is a (slightly more recent) test from October 2023: https://wiki.secondlife.com/wiki/File:Second_Life_Logo.svg
And the error given is:
Error creating thumbnail: convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ error/delegate.c/InvokeDelegate/1928. convert-im6.q16: unable to open file `/tmp/magick-4352gcUpm5k4VXzw': No such file or directory @ error/constitute.c/ReadImage/600. convert-im6.q16: no images defined `PNG:/tmp/transform_553c1ae0c6da.png' @ error/convert.c/ConvertImageCommand/3258.
This is an error message from ImageMagick 6, used to resize thumbnails, and a prerequisite for uploading images. With all other (supported) image types (including WebP!) everything works without errors, because all of those are natively supported by ImageMagick (i.e., they're built-in modules).
Several other graphic file formats — the most obvious and pertinent of those being SVG, but others, such as PDF, might have similar issues — aren't natively handled by ImageMagick; rather, depending on the underlying operating system, they are handled by what ImageMagick calls
delegates
. A delegate is simply an external tool which converts first the 'foreign' file to a format that ImageMagick can handle natively; this will then be further processed by ImageMagick (and all its, well, magic
, applied as normal). In other words: for SVGs, the first
step in the complex ImageMagick pipeline is to convert the file to something ImageMagick can process.Usually, that means rasterising the vector file to an adequate size. On macOS, for instance, for some reason, my MacBook Pro uses Inkscape; on Ubuntu and Debian Linux,
rsvg-convert
is more common.The full delegate lis can be retrieved from a file called
delegates.xml
which, under Debian and Ubuntu, is found under /etc/ImageMagick-X/
(where X is the ImageMagick version — 6 in the case of the SL Wiki). This should also list the kind of command arguments passed to rsvg-convert
.What
seems
to be happening is that rsvg-convert
is being correctly called, but it's unable to write a temporary file (the intermediary conversion file to a raster format) on /tmp
— possibly because the process running the MediaWiki PHP does not have read/write access to /tmp
— and therefore is unable to pass the results back to ImageMagick.Please note that the MediaWiki installation
may
be using the ImageMagick module for PHP, as opposed to launching an external process; this means that common file formats are handled directly inside PHP itself. External delegates, however, need to be spawned; and it's very likely that the PHP support on that server does not have direct access to /tmp
, and, therefore, anything spawned by it will inherit its permissions (or lack thereof).Also note that the upload itself didn't fail: the SVG
has
been correctly stored — the link is obtained by clicking on the Time/Date column of the File: Second_Life_Logo.svg
page. It's only
the thumbnail that is broken; but without a valid thumbnail, nothing works on the SL Wiki.This should be a very easy fix! After all,
before
September 2022, there was no problem in uploading SVGs. But now all are broken.Log In
Spidey Linden
Merged in a post:
"Error creating thumbnail" message on SL wiki, breaking images
Erik Mondrian
On Dec 1, 2025, I noticed that images seem to be broken all across the official SL wiki, replaced by the following message: "Error creating thumbnail: Unable to save thumbnail to destination"
Nearly two weeks later and the issue still persists, affecting almost every wiki page I've looked at. Some examples include https://wiki.secondlife.com/wiki/Good_Building_Practices and https://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory (where a couple images occasionally appear to show up okay, but not all of them).
This issue is especially problematic for pages like https://wiki.secondlife.com/wiki/Linden_Lab_Official:New_Linden_Homes_2019 which uses images to show off the various Premium LH themes of Bellisseria. Right now, it's just text, with all of the images missing.
Erik Mondrian
Just making sure that the Lab is aware of this ongoing issue, especially since it hasn't even been marked as "Tracked" yet. Juniper Linden Spidey Linden Kermit Linden
Gwyneth Llewelyn
Reported on https://feedback.secondlife.com/web-bugs/p/sl-wiki-please-fix-svg-support-old-issue-reported-on-jira as well — the brokenness started with SVG files only, now it's really
everything
.The culprit is exactly what Gloss Doll explained: lack of permissions on the server to write on the
/tmp
directory, which shouldn't be the case. Or, alternatively, the disk may
be full (the wiki itself is not directly affected, since it runs mostly from a database server; but anything written locally will break).Also note that about the same time (most) images stopped appearing, the syntax highlighting broke
again
. These are very likely all related issues to the same problem: lack of permissions or lack of disk space (or lack of access
to the disk, if it's actually remotely mounted, say, on AWS via the S3 API).stevey1 Resident
pretty sure the tpv page just loaded fine for me this time (hope sl runs better today fingers crossed)
Gloss Doll
I've definitely encountered this issue on the wiki as well.
I've seen this issue appear before on another organization's MediaWiki install, but I don't know exactly what the cause of the problem is.
In that organization I was able to do some exploratory googling on the organization's behalf to try and move us towards a solution.. and the results I found suggested that there might be either a permissions issue in relation to the creation of thumbnail images, something that broke when a version update was applied, some other misconfiguration (in the mistaken name of 'security') that resulted in a lack of ability for the image handling system to function, or possibly a media storage location that was full.
Resources I found:
"[RESOLVED] MW 1.21 Error creating thumbnail: Unable to save thumbnail to destination" mediawiki help thread
"Error creating thumbnail: Unable to save thumbnail to destination" (fixed) mediawiki help thread
"Error creating thumbnail: Unable to save thumbnail to destination" mediawiki help thread
...
Gloss Doll
...And perhaps most relevant, this article from the
MediaWiki help documentation
:MediaWiki Errors
Image Thumbnails not working and/or appearing
This section lists problems and solutions relating to thumbnails not rendering or displaying.
...
Unable to save thumbnail to destination
If you get the error "Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination" and the
$wgUploadDirectory
directory has the correct permissions (at all levels), check that $wgTmpDirectory
actually exists. (Unlike some path variables such as $wgCacheDirectory
, $wgTmpDirectory
is not created at runtime.) A more detailed error message may be available if you turn on logging with $wgDebugLogFile
.This error can also occur when read only mode (
$wgReadOnly
) has been set in LocalSettings.php
. You can try to remove $wgReadOnly
to see if that solves the issue for you.Gwyneth Llewelyn
... and another update!
Since at the moment of writing (early May 2025) the SL Wiki is undergoing monitoring/maintenance, who knows, maybe this issue can be solved somehow.
I also found that @signpostmarv.martin has attempted to categorise all broken images here:
Gwyneth Llewelyn
Slight update: back in 2022, I thought that this issue was 'new', in the sense that it would only apply to anything uploaded from 2022 onwards (well, maybe a bit earlier, since it's not every day that I upload SVGs to the SL Wiki).
However, after doing some searches on the Gallery of files, it seems that
all
of them are broken — dating back to 2008 (at least)!Interestingly, while
some
pages haven't bothered with the 'broken-ness' — they possibly assumed it was just a 'temporary glitch' — there was a systematic attempt made by one resident in 201
2 (not 2022!) to get a SVG upload that worked. Judging from the results, it didn't work. However, that does not necessarily mean that "everything was broken" back then — there might have been some legitimate issues with that resident's SVG.SL Feedback
Hello, and thank you for your detailed report regarding the SVG upload issue on the SL Wiki. This problem has indeed been brought up in the past and is currently tracked. We understand the importance of having functional SVG support, especially for maintaining the quality and usability of the Wiki. While we don't have an estimate for when this issue might be resolved, please rest assured that it is on our radar. We appreciate your patience and your effort in providing such a comprehensive description. Your input is invaluable in helping us improve Second Life. Thank you!
Gwyneth Llewelyn
SL Feedback my pleasure! I hope you can get it fixed :)
SL Feedback
marked this post as
tracked
Gwyneth Llewelyn
SL Feedback I guess that after another year has elapsed, and even taking into account that other parts of the Wiki have been corrected, SVG uploads still fail with the same error as before.
Interestingly, I stumbled upon an ancient SVG upload of the old "Snowglobe" logo — done by a member of the Linden staff back in... 2008? So, allegedly this functionality has been broken for the past 17 years (as of 2025).
If that's the case, one would imagine that even a 17-year-old, conceived back then with the specific purpose of fixing this Wiki issue, will probably become an adult next year, and
then
they'll be allowed to fix things and
receive money for their efforts 😁