https://bugzilla.wikimedia.org/show_bug.cgi?id=22881
Tim Starling <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #24 from Tim Starling <[email protected]> 2011-08-26 06:01:50 UTC --- Conformance to the site style <http://www.mediawiki.org/wiki/Manual:Coding_conventions> is a requirement for core code contributions. I'm not sure what the point is of this multipart/related document type: is there some client that can read it? The exports appear to be sent out with HTTP headers specifying Content-Type: application/xml, but with a body that is plainly not XML, rather it is this MIME message format with headers embedded in the body text. It seems like zip would have been a better choice. The wording of the messages which enable this multipart format certainly don't warn the user that what they are going to get will be so exotic. What does this: /*op-patch|TS|2010-04-26|HaloACL|SafeTitle|start*/ signify? It is wrapped around some strange-looking code. Is it meant to be there? The 5000-page limit in SpecialExport::getPagesFromCategory() appears to have been removed without explanation. Also, SpecialExport::rgetPagesFromCategory() appears to have no recursion depth limit. It's probably feasible to use the upload timestamp of the old image version to generate the archive name, but it would need to be done with a bit more care and analysis than I see here. For example, LocalFileRestoreBatch::execute() appears to need patching. Deployment would be difficult since it would break if MediaWiki is downgraded or run with multiple versions on the same database. It would be simpler, and head off potential future problems with analysis of image filesystems, if the archive names could be changed to a completely different regime, adding some marker to show whether they were generated the old way or the new way. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
