Last modified: 2014-01-13 21:27:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T60151, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 58151 - Collection exports everything to PDF regardless of chosen format (epub, openzim, odt)
Collection exports everything to PDF regardless of chosen format (epub, openz...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Collection (Other open bugs)
master
All All
: Highest major with 2 votes (vote)
: ---
Assigned To: Matt Walker
:
: 58227 (view as bug list)
Depends on:
Blocks: Wikisource
  Show dependency treegraph
 
Reported: 2013-12-07 12:55 UTC by Marcin
Modified: 2014-01-13 21:27 UTC (History)
16 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Marcin 2013-12-07 12:55:15 UTC
Hi,
I am trying to export a book as epub however no matter which download format I choose it always servers only pdf file.
Steps to reproduce:
1) open an article
2) export/print
3) create new book
4) add this page to your book
5) show book
6) insert some title
7) pick e-book (EPUB) from drop down list in "Download" section
8) After rendering is finished click on "download the file"
9) a pdf file (instead of a file in epub format) is being downloaded

Same thing happens no matter what format (EPUB/OpenZIM/OpenDocument) i choose.

When I'm hoovering over the download link (from step 8) the underlying url looks as follows:

http://en.wikipedia.org/w/index.php?title=Special:Book&bookcmd=download&collection_id=4f827953119e6031&writer=epub&return_to=Special%3ABook

Best Regards,
Marcin
Comment 1 Marcin 2013-12-07 13:01:16 UTC
I've reproduced the problem on Google Chrom, Firefox and Safari on MacOS X 10.8. and on Firefox and Chromium on Ubuntu Linux.
Comment 2 Uwe L. Korn 2013-12-07 15:31:44 UTC
Seems to be introduced with https://gerrit.wikimedia.org/r/#q,734de04a,n,z

One problem I see is that $writer in RenderingAPI.php is never actully used.
Comment 3 Andre Klapper 2013-12-09 20:00:38 UTC
*** Bug 58227 has been marked as a duplicate of this bug. ***
Comment 4 Andre Klapper 2013-12-09 20:04:03 UTC
Bug 57975, bug 57920 and bug 58151 are currently investigated by mwalker.
Comment 5 Matt Walker 2013-12-09 22:10:45 UTC
It's not that we don't use $writer anywhere (it get's assigned as an instance variable and then used in the subclass MWServeRenderingAPI.) That being said I'm not sure what's going on. My local instance is apparently broken for other reasons so...

I'm going to in a little bit (2013-12-09T23:00 UTC) `git bisect` the code running in production to find the offending commit.
Comment 6 Matt Walker 2013-12-09 22:13:05 UTC
*** Bug 57975 has been marked as a duplicate of this bug. ***
Comment 7 David Corral Gadea 2013-12-09 23:46:57 UTC
Buenas, he visto que también tengo el mismo problema, he probado con varios navegadores, chrome y firefox actualizados a dia 10 diciembre 2013.
Comment 8 Matt Walker 2013-12-09 23:58:51 UTC
So it's definitely https://gerrit.wikimedia.org/r/#/c/95483/ that caused it. Now to figure out why...
Comment 9 Gerrit Notification Bot 2013-12-12 20:25:47 UTC
Change 101062 had a related patch set uploaded by Mwalker:
Revert "Rewrite of interaction with renderer"

https://gerrit.wikimedia.org/r/101062
Comment 10 Gerrit Notification Bot 2013-12-12 20:28:27 UTC
Change 101062 merged by MaxSem:
Revert "Rewrite of interaction with renderer"

https://gerrit.wikimedia.org/r/101062
Comment 11 Gerrit Notification Bot 2013-12-12 21:32:06 UTC
Change 101108 had a related patch set uploaded by Mwalker:
Change Collection to a deploy branch

https://gerrit.wikimedia.org/r/101108
Comment 12 Matt Walker 2013-12-13 00:17:22 UTC
So the problem still exists in master; I've just pinned the collection extension to a branch that has a the offending patch reverted. This has now been deployed.
Comment 13 Rob Lanphier 2013-12-13 00:54:01 UTC
Hi Matt, could you revert this in master as well until you have a fix?  It's really not good practice to leave master in a known-broken state.  We deploy pretty frequently these days, and this seems like a trap.
Comment 14 Matt Walker 2013-12-13 02:17:06 UTC
I changed the deploy scripts so that new branches pull from my pinned revision. Part of the issue of pulling it from master is that the only platform I have to test on is production (I've not yet had the time to get a beta labs instance setup and for some reason my labs install is completely borked in a different way.)
Comment 15 Ralf Schmitt 2013-12-13 08:15:43 UTC
Does that mean you didn't even test this change before it went into production?
Comment 16 Matt Walker 2013-12-13 18:26:17 UTC
Heh; no we tested it :) I tested it locally to ensure that the before / after output to mwlib was the same; and I tested it on my sandbox in labs w/ mwlib with PDF rendering (and our alternate renderer.)

Apparently however the configuration between my local and production is different... And I didn't test multiformat to the same renderer because the code made that seem like it was being exported to a third party render platform (which given that I was able to export to two render platforms it seemed like I'd covered that test case.)
Comment 17 Gerrit Notification Bot 2013-12-17 18:34:56 UTC
Change 101108 merged by Reedy:
Change Collection to a deploy branch

https://gerrit.wikimedia.org/r/101108
Comment 18 Andre Klapper 2014-01-09 14:07:42 UTC
mwalker: Can this be closed as RESOLVED FIXED, or is work left to do?
Comment 19 Matt Walker 2014-01-10 00:25:07 UTC
Looks like it's working in wmf10 (which is what deployed with it today.) So yes, marking as resolved fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links