Extension:SVGEdit

From Linux Web Expert

Revision as of 10:08, 26 February 2024 by imported>Jdforrester (WMF) (Restore space.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

MediaWiki extensions manual
SVGEdit
Release status: experimental
File:SVGEdit extension screenshot.png
Implementation User interface, Ajax
Description In-browser vector graphics editing with SVG-edit
Author(s) Brooke Vibbertalk
MediaWiki 1.17+
License GPL (extension), Apache (SVG-edit)
Download
  • $wgSVGEditInline
  • $wgSVGEditEditor
Quarterly downloads Lua error in Module:Extension at line 172: bad argument #1 to 'inNamespace' (unrecognized namespace name 'skin').
Public wikis using Lua error in Module:Extension at line 172: bad argument #1 to 'inNamespace' (unrecognized namespace name 'skin').
Translate the SVGEdit extension if it is available at translatewiki.net

The SVGEdit extension provides in-browser creation and editing of uploaded SVG files using the very nice open-source SVG-edit widget. Visit the GitHub repository or try the SVG-edit demo now.

Batteries not included: Neither SVG-edit 2.5.1 nor 2.6 is included at present.

Current versions of most major browsers should work. Internet Explorer 8 and earlier will require Chrome Frame plugin even with SVG-edit 2.6. IE 9 and later only need Chrome Frame with SVG 2.5.1 or earlier

  • "Edit drawing" tab and button added on File: pages for SVG images
  • "SVG drawing" button added to WikiEditor advanced toolbar "insert" section to create new files conveniently while working on a page
    • file invocation is added to the text editor upon saving the file
    • currently the filename will be autogenerated from the name of the page being worked on

Installation

  • <translate> [[<tvar name=2>Special:ExtensionDistributor/SVGEdit</tvar>|Download]] and move the extracted <tvar name=name>SVGEdit</tvar> folder to your <tvar name=ext>extensions/</tvar> directory.</translate>
    <translate> Developers and code contributors should install the extension [[<tvar name=git>Special:MyLanguage/Download from Git</tvar>|from Git]] instead, using:</translate>cd extensions/
    git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/SVGEdit
  • <translate> Add the following code at the bottom of your <tvar name=1>LocalSettings.php </tvar> file:</translate>
    wfLoadExtension( 'SVGEdit' );
    
  • Download SVGedit (from GitHub), and place it in .../extensions/SVGEdit/svg-edit
  • Enable SVG support
  • File:OOjs UI icon check-constructive.svg <translate> Done</translate> – <translate> Navigate to <tvar name=special>Special:Version</tvar> on your wiki to verify that the extension is successfully installed.</translate>

Configuration

There is only one configuration option, which allows using an externally hosted instance of the SVG-edit editor iframe:

$wgSVGEditEditor = 'URL to Svg Editor';

This can be used to run the editor off a faster static-file server, to provide a separate JavaScript security context by running the editor on another domain, or just to try a new version of the libraries.


The svgeditor used in Wikimedia wikis is hosted at WMF Labs, and can be used as shown below:

#Example: 
$wgSVGEditEditor = 'http://tools.wmflabs.org/svgedit/editor/svg-editor.html';

Development

While the master code for this extension lives in Wikimedia's git repository, I also have a git repo where I may have some experimental branches:

 http://gitorious.org/mediawiki-svgedit/mediawiki-svgedit

Known bugs

Todo

  • add an editor trigger on SVG images visible in regular page views (partially implemented, not yet ready)
  • allow saving without closing the editor
  • autosave & recover drafts
  • build a Gadget/user-script shim, allowing end-users to add editing to SVG-supporting wikis themselves (needs a JSONP proxy to load files for Wikimedia usage, since ApiSVGProxy is not in favor and there's been no motion to change cross-origin headers)
  • extend 'import SVG file' and 'image' tools to allow pulling other images from the wiki

Notes

While SVG-edit is pretty capable, it's still a bit experimental and may damage existing files. Always check to make sure things still look right after a save; remember you can always revert to the previous version.

The editor widget is loaded in an ‎<iframe> within the current page context; after saving, the parent page is reloaded which should show the new version of the file.

Those using a separate domain to store files may need to enable ApiSVGProxy to load up existing SVG files. Cross-origin headers on the file server should also be able to resolve this, but this needs testing.

Saving is implemented by POSTing an upload request to the API from an XMLHTTPRequest; this does not require any extra tweaks other than making sure SVG files are allowed for upload.

Security

Communication with the actual SVG-edit tool is done via the iframe's postMessage interface, which allows limited communication across domains. Specifying a separate location for the SVG-edit instance allows running the editor on another domain, and thus separate JavaScript context, to reduce the attack surface from potentially evil SVG code.

Be aware that using an instance of SVG-edit hosted by a third-party can expose your actual SVG image data to client or server code on that domain. If using an external editor instance on a private MediaWiki, you should ensure that you trust the domain that you use.

Related

See also