Exporting to MediaWiki via File | Export | MediaWiki (.txt) results in: "Error writing the document, write problem. The file could not be written." Seems to occur on at least OS X and Windows, independent from the content of the exported file.
Created attachment 58181 [details] Simple file which causes an error
Created attachment 58182 [details] Empty conf.?
Confirmed with Windows XP32, LO 3.5.1 RC2
*** Bug 48125 has been marked as a duplicate of this bug. ***
Hey This bug still exist on 3.5.2 rc2
Created attachment 59451 [details] console errors I reproduced this behaviour on Debian pc 86-64, 3.5 branch updated yesterday. The problem is mmltex.xsl isn't found (see attachment to have details)
Not a major bug.
(In reply to comment #7) > Not a major bug. We ship the extension, so must make sure that it works.
I think exporting to Wiki format would be very useful. I keep looking for ways to do this and keep hoping for LibreOffice to have this feature.
@gabriel: pls don't touch the version field, unless setting it to the *earliest* version in which the bug can be found. Thanks ;-) Cor
Hi @Cor, Sorry about that, didn't know this rule ;) Make sense for sure. Thanks!
(In reply to comment #11) > Sorry about that, didn't know this rule ;) Make sense for sure. No problem Gabriel. Too many rules to read before starting to work ;-) Thanks for your help! Cor
*** Bug 49387 has been marked as a duplicate of this bug. ***
Stephan - I wonder if this is another gbuild / component registration snafu ?
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=29b7738085c4fb272b845900ef908f621d02cd68 fdo#46509: xsltml .xsl files missing from wiki-publisher.oxt
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7a1e17c4fdea4103e7f921e8cd9c315c1dbe612> "convert swext to gbuild and add to tail_build" -- apparently inadvertently -- dropped a number of files from wiki-publisher.oxt. With the fix from comment 15, "File - Export... - Media Wiki (.txt)" no longer results in an error. Looking at the content of a wiki-publisher.oxt built for LO 3.4 (before the gbuild'ification of swext) and one built for current master (with the fix from comment 15): $ comm -3 \ <(unzip -lqq lo-3.4/bootstrap/solver/340/unxlngx6.pro/bin/wiki-publisher.oxt \ | sed -e 's/.* //' | sort) \ <(unzip -lqq lo-master/solver/unxlngx6/bin/wiki-publisher.oxt \ | sed -e 's/.* //' | sort) components.rdb description-de.txt description-en-US.txt filter/ filter/math/ help/ help/component.txt help/de/com.sun.wiki-publisher/wikiaccount.xhp help/de/com.sun.wiki-publisher/wikiformats.xhp help/de/com.sun.wiki-publisher/wikisend.xhp help/de/com.sun.wiki-publisher/wikisettings.xhp help/de/com.sun.wiki-publisher/wiki.xhp help/en-US/ help/en-US/com.sun.wiki-publisher/ help/en-US/help.db_ help/en-US/help.ht_ help/en-US/help.idxl/ help/en-US/help.idxl/_0.cfs help/en-US/help.idxl/segments_3 help/en-US/help.idxl/segments.gen help/en-US/help.jar help/en-US/help.key_ license/ registration/ registration/LICENSE templates/ templates/MediaWiki/ WikiEditor/ * components.rdb new in master is due to conversion to passive UNO component registration * explicit directories (ending in /) no longer in master is a harmless consequence of gbuild'ification * help/de new in master is due to my 3.4 being built without --with-lang=de But for the other differences, I do not know if any of them are by design or in error. Therefore, I would appreciate it if somebody knowledgeable about how to operate wiki-publisher.oxt would check whether everything works as expected in a master build including the fix from comment 15, and mark this bug as fixed then. If that is the case, I intend to get the fix from comment 15 backported to libreoffice-3-5.
patch looks great; whether the fix is complete is open to question - but it can't be worse :-) Pushed to -3-5 and tentatively closing pending further feedback. Thanks Stephan ! :-)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=162c9e3c025370dcbe962990c4c8f6df29c6c7cc&g=libreoffice-3-5 fdo#46509: xsltml .xsl files missing from wiki-publisher.oxt It will be available in LibreOffice 3.5.4.
Thanks from me, too. This feature is very important to me, so I'll be happy to test it on some kind of a nightly build, if there is anything like that in LibO.
(In reply to comment #19) > Thanks from me, too. > > This feature is very important to me, so I'll be happy to test it on some kind > of a nightly build, if there is anything like that in LibO. Here you go http://dev-builds.libreoffice.org/daily/
(In reply to comment #19) > This feature is very important to me, so I'll be happy to test it on some kind > of a nightly build, if there is anything like that in LibO. <http://lists.freedesktop.org/archives/libreoffice-qa/2012-May/001653.html> "Check recent master wiki-publisher.oxt": "For example, <http://dev-builds.libreoffice.org/daily/Linux-x86_64_11-Release_Configuration/master/2012-05-13_12.41.51/master~2012-05-13_12.41.51_LibO-Dev_3.6.0alpha0_Linux_x86-64_install-deb_en-US.tar.gz> apparently includes the necessary fix from bug 46509." You can tell if a LO installation set contains the fix by checking whether it contains a file .../share/extensions/wiki-publisher/filter/math/cmarkup.xsl.
(Just for the record: Keeping the description.xml version value of the bundled wiki-publisher.oxt at 1.1.1 for libreoffice-3-5 after the push of <http://cgit.freedesktop.org/libreoffice/core/commit/?id=162c9e3c025370dcbe962990c4c8f6df29c6c7cc&g=libreoffice-3-5> seems to be OK, as those changes do not require re-synchronization of extensions' per-user configuration data -- which would only happen for bundled extensions if their version values are bumped. For master towards LO 3.6, the version value of wiki-publisher.oxt had recently been bumped to 1.1.2 anyway with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=fefd1b5f8ffd902e483decfecef80f3498b2d0a8> "Bump extension versions after changing to passive registration.")
This seems to work in 4.0.x and 4.1.x, so tentatively closing. Please reopen if it is still completely broken. Open new bugs if you have specific problems with the export.
Since there's no specific fix, I put it as WFM.