Ah, looks like I missed a string change when I added WXR support that actually broke manual BlogML format exports. Thanks for pointing that out, I just made a change to the code on Github to fix that.
I did some experimenting and have figured out the issue, which does appear to only happen in Safari. Apparently the Content-Type of text/xml was convincing Safari to try and display the feed instead of download it. Changing that to application/octet-stream fixed the issue. To be clear, this would have been a problem with either export format, they are both handled the same. And using the readfile() change should be highly discouraged, it is not intended to work with file contents (only the filename), and this functionality seems to be an unintentional result of the way PHP internally opens the stream. Both changes are available on Github and that's the source that should be used, if there is a version in -extras still it should have been removed - I'll check on that momentarily. On Sep 16, 2011, at 10:26 AM, Bryce wrote: > This is what I was talking about over IRC, when I wanted both to > work. I am looking through the code right now over github and I see > two options for the plugin, "export" and "export as WXR". export does > not export to BlogML, but takes me somewhere else in the admin, in > which I can only export as WXR, which Safari believes is an ordinary > RSS feed and will not download the document. Currently, I am using the > trunk version that was available in the plugin directory with Habari > 0.7.1. In the function that starts on line 41, you do not have a > default selection for the switch statement. When I add an option to > export to BlogML, only one option outputs anything, while the other is > blank, with the code as is. When I use readfile(), the data for both > is present, but only one has no presence of readfile() surrounding the > XML info. > > On Sep 16, 6:48 am, Chris Meller <[email protected]> wrote: >> This still perplexes me. I've yet to be able to duplicate this particular >> issue and don't see how it could happen when the proper header is being sent >> - millions of files are downloaded every day by throwing a >> Content-Disposition header. >> >> Also, the fix confuses me. readfile(), per the documentation, accepts a >> filename and not a string of content, which the $xml variable is - there is >> no physical file. And all it does is immediately read in a file and output >> it to the buffer, which is exactly what echo is doing. >> >> BTW, if you're changing line 200 in the download method it would work for >> either format, they are both handled identically except for the generation >> steps and they both *do* work, there are options in the plugin drop button >> to export as your desired format. >> >> On Sep 16, 2011, at 12:07 AM, Bryce wrote: >> >> >> >> >> >> >> >>> You're welcome. It only works for the WXR portion. The BlogML export >>> portion is not enabled (even though the code for the option exists, >>> it is not present in the area where the plugin draws its choices >>> from), so it will break this suggestion, if one tries to enable >>> BlogML. >> >>> On Sep 4, 9:46 am, jtrag <[email protected]> wrote: >>>> Thanks for the update! >> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group >>> athttp://groups.google.com/group/habari-dev > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/habari-dev -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
