Opened 18 years ago
Closed 18 years ago
#3225 closed defect (bug) (fixed)
Export file does not download in FF
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.1 | Priority: | normal |
Severity: | normal | Version: | 2.1 |
Component: | Administration | Keywords: | export has-patch needs-testing |
Focuses: | Cc: |
Description
Latest SVN as of the time of this post. Clicking on "Download Export File" on the export page takes me to the XML file. It doesn't offer it up for download. FF2.0RC2, haven't tried in IE or anything else.
Attachments (2)
Change History (18)
#2
@
18 years ago
Missed the Fx 2.0 boat, but it should wind up in 2.0.0.1.
If that's bad timing for a WP release, you can work around it with a 512 byte comment (<!-- Content sniffing is evil. Really evil. Really, really evil. ... -->) between the XML decl and the root element. No idea if that will keep Safari's nose out of your non-feed, though.
#3
@
18 years ago
This all comes down to the timing for FF 2.0.0.1 If we're ready to release WP 2.1 and FF 2.0.0.1 isn't out with a fix, we should probably take Phil's advice regarding the 512 byte comment. If FF is fixed after, we can take it out in a 2.1.1 release.
Safari is a different matter. I don't think Safari is sniffing the content. Sending as text/plain fools Safari.
How important is it to send text/xml like we're doing now? It's supposed to be a download, so as long as it gets handled as text, what's the harm in sending it as text/plain?
#4
@
18 years ago
I dunno how vBulletin does it, but I can click a button to download my theme as a XML file and it pops up a download box as it should.
You guys are doing something wrong. :P
#5
@
18 years ago
Okay, I found it in vB's source and here's what it sends:
header('Content-Type: ' . $filetype); header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT'); header('Content-Disposition: attachment; ' . $filename); header('Content-Length: ' . strlen($filestring)); header('Cache-Control: must-revalidate, post-check=0, pre-check=0'); header('Pragma: public'); echo $filestring; exit;
I'd paste the whole file_download()
function and the tweaks it does to $filename
, but the vB license doesn't allow me to redistribute it's code and I don't want to risk it anymore than I have just done now. ;)
#6
@
18 years ago
Viper007Bond you do not tell us what version of Firefox you are experiencing the problem with? If Firefox 2, it should be resolved in the 1st maint release of Firefox 2.
I imagine vBulletin is not doing anything more correctly, they just get lucky with this bug.
#8
@
18 years ago
3225.diff
- Pads export file with helpful comments to fix FireFox 2 issue.
- Sends ~made-up Content-type: text/wxr+xml to fix Safari Issue.
Works in
- FF 2
- FF 1.5.0.7
- Safari 2.0.4
- Opera 9.02
- IE 7
Not tested in IE 6
#10
@
18 years ago
- Keywords 2nd-opinion removed
Has been deployed on wordpress.com for about a week and no issues identified. Removing '2nd-opinion' keyword though opinions always welcome.
#12
@
18 years ago
- Keywords 2nd-opinion export added; has-patch removed
- Resolution fixed deleted
- Status changed from closed to reopened
As posted at wp-hackers, I don't think text/wxr+xml
is a good choice of media type. I'd recommend something like application/prs.wordpress.export+xml
. (Or application/vnd.automattic.wxr+xml
, or whatever. There are plenty of options.)
For background, check out RFC4288 and the IANA media type registry.
#14
@
18 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Still broken in IE7
Still broken on IE7.
Fix: use text/xml (which will make people happy :) ). I've searched far and wide and this is the only way to get things working in IE7.
That breaks Safari unless we pad the file with an even more verbose message.
Attached tested on IE7, IE6 (may not respect content-disposition filename), FF2, Safari latest, Opera latest.
Unfortunately, FF2.0RC2 is sniffing the content of the file, and serving it up to your designated feed reader (or apparently, viewing in-browser if no feed reader is designated), totally IGNORING the Content-Disposition header. Even sending it as text/plain doesn't work (although it fools Safari, which appears to also ignore Content-Disposition for things sent with text/xml).
See: http://weblogs.mozillazine.org/ben/archives/010116.html
One way to get around it might be to compress the XML into a gzip (or zip) file before offering it for download. That'd speed up the download, but I don't know how much longer the server would have to chew on it, and people with 8MB for PHP might be in trouble... I know that PHPMySQL's compression option has bitten me before, leaving me with corrupted gzip files.
Hopefully this behavior will be fixed by 2.0 release.
Here's the Firefox bug ticket (opened a few days ago):
https://bugzilla.mozilla.org/show_bug.cgi?id=355332
We still have to deal with Safari, however.