Unable to export .odt files from Pressbooks

When attempting to export .odt files I receive the following error:

   [time] => Tue Jun 18 17:57:10 2019
   [user] => jsmith
   [site_url] => http://openbooks.library.umass.edu/disability
   [blog_id] => 3
   [theme] => McLuhan
   [url] => http://openbooks.library.umass.edu/disability/format/xhtml?timestamp=1560880583&hashkey=fdc5c2d6fdd72d97229de56237f7068d
Transformation failed, encountered a problem with  [ content ] [ mimetype ] [ meta ] [ settings ] [ styles ] 

I/O error reported by XML parser processing file:/tmp/2H2MOg/source.xhtml: http://www.w3.org/TR/xhtml11/DTD/xhtml-datatypes-1.mod

The systems person at my institution says:

Pressbooks is coded incorrectly to require access to system tmp files, apache and thus php has no access to them. This seems to be a bug with Pressbooks


Pressbooks: 5.8.2
Wordpress: 5.2.2

As of PHP 5.5.0 you can set the sys_temp_dir INI setting so that the sys_get_temp_dir function will return a useful value when the default temporary directory is not an option.



This was apparently tried and did not work.

Here’s the code. Patches welcome:

Maybe the community can take over from here? It’s clearly working for everyone else who hasn’t encountered this permissions issue… GitHub pull requests that fix incorrect code always appreciated!

Thanks @dac.chartrand.

At this point, our systems folks are thinking that the only thing that might work is putting the temp directory within the webroot, which they are worried would cause a big security problem as it would expose any temp files to the world, (user information, passwords, etc.)

According to our programmer there appears to be an xslt error because PB uses a seemingly old dtd

This is the error.

I/O error reported by XML parser processing file:/var/www/htmltemp/lfhgsdlkfghsd#%@#$asdfasdf/source.xhtml: http://www.w3.org/TR/xhtml11/DTD/xhtml-datatypes-1.mod

The output from the script uses the dtd http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd and that dtd as referred by the w3.org includes a type mod of https://www.w3.org/TR/xhtml11/DTD/xhtml-datatypes-1.mod And that file does not exist on the w3.org site.

1 Like

Hmm, I don’t think the complaint is coming from Pressbooks. I think it’s comming from saxon-he.jar If we do /usr/bin/java -jar /opt/saxon-he/saxon-he.jar on the servers we run we get (among other --help type info):

  • Saxon-HE from Saxonica

This is the version of Saxon-HE we specify in our docs (near upgrade/downgrade accordingly).

Generally everything in Pressbooks works with the latest version of whatever is on a linux distro, but this one might be more finicky. is still available for download. It is not the latest version.

First, I’d check what version of saxon-he you are running. If it’s not I would try to install that.

If you are unwilling to install (possibly related to your other post of". We cannot install older versions") then you’ll have to wait until we look at ODT/Word imports/exports in a future sprint. One of the ideas thrown around is to refactor to use PHP Office/PHP Word. This would remove the Saxon-HE dependency from our code entirely.


The response:

This is not a version specific issue to saxon, I tested the xml transformation in several tools, the dtd is broken on the [w3.org] (http://w3.org/) side. The only thing an older version/different tool can do is not fail when the file is not found, and the specification says to stop if parts cannot be loaded.

Hi Jeremy,
I can’t speak very knowledgeably to the technical issues that you’re encountering or the theories being reported by your programmer, but I can report that I am able to produce odt exports quickly and easily without failure on our hosted Pressbooks networks (here’s an example I just produced this morning). I was going to try to do the same thing with the book you linked to, but it’s private and unavailable for cloning.

Thanks @SteelWagstaff. Here are two that are public:


Hi Jeremy,
It took me about a minute to import the GWS book and about 10 seconds to make a successful ODT export on one of our hosted networks (see that file here). I think we’ve done about all we can do here. As Dac noted earlier, this is working for us and for everyone else who hasn’t encountered the permissions issue you’re describing. If you do identify a fix that would resolve this on your network, I’m guessing others in the community would welcome details of how you resolved the problem and we’d be willing to review a relevant pull request.