Collection exports everything to PDF regardless of chosen format (epub, openzim, odt)
Closed, ResolvedPublic

Description

Author: marcin.iwinski

Description:
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


Version: master
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57975
https://bugzilla.wikimedia.org/show_bug.cgi?id=57920

bzimport set Reference to bz58151.
bzimport created this task.Via LegacyDec 7 2013, 12:55 PM
bzimport added a comment.Via ConduitDec 7 2013, 1:01 PM

marcin.iwinski wrote:

I've reproduced the problem on Google Chrom, Firefox and Safari on MacOS X 10.8. and on Firefox and Chromium on Ubuntu Linux.

bzimport added a comment.Via ConduitDec 7 2013, 3:31 PM

uwelk wrote:

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.

Aklapper added a comment.Via ConduitDec 9 2013, 8:00 PM
  • Bug 58227 has been marked as a duplicate of this bug. ***
Aklapper added a comment.Via ConduitDec 9 2013, 8:04 PM

Bug 57975, bug 57920 and bug 58151 are currently investigated by mwalker.

bzimport added a comment.Via ConduitDec 9 2013, 10:10 PM

mwalker wrote:

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.

bzimport added a comment.Via ConduitDec 9 2013, 10:13 PM

mwalker wrote:

*** Bug 57975 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitDec 9 2013, 11:46 PM

info wrote:

Buenas, he visto que también tengo el mismo problema, he probado con varios navegadores, chrome y firefox actualizados a dia 10 diciembre 2013.

bzimport added a comment.Via ConduitDec 9 2013, 11:58 PM

mwalker wrote:

So it's definitely https://gerrit.wikimedia.org/r/#/c/95483/ that caused it. Now to figure out why...

gerritbot added a comment.Via ConduitDec 12 2013, 8:25 PM

Change 101062 had a related patch set uploaded by Mwalker:
Revert "Rewrite of interaction with renderer"

https://gerrit.wikimedia.org/r/101062

gerritbot added a comment.Via ConduitDec 12 2013, 8:28 PM

Change 101062 merged by MaxSem:
Revert "Rewrite of interaction with renderer"

https://gerrit.wikimedia.org/r/101062

gerritbot added a comment.Via ConduitDec 12 2013, 9:32 PM

Change 101108 had a related patch set uploaded by Mwalker:
Change Collection to a deploy branch

https://gerrit.wikimedia.org/r/101108

bzimport added a comment.Via ConduitDec 13 2013, 12:17 AM

mwalker wrote:

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.

RobLa-WMF added a comment.Via ConduitDec 13 2013, 12:54 AM

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.

bzimport added a comment.Via ConduitDec 13 2013, 2:17 AM

mwalker wrote:

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.)

bzimport added a comment.Via ConduitDec 13 2013, 8:15 AM

ralf_wikimedia wrote:

Does that mean you didn't even test this change before it went into production?

bzimport added a comment.Via ConduitDec 13 2013, 6:26 PM

mwalker wrote:

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.)

gerritbot added a comment.Via ConduitDec 17 2013, 6:34 PM

Change 101108 merged by Reedy:
Change Collection to a deploy branch

https://gerrit.wikimedia.org/r/101108

Aklapper added a comment.Via ConduitJan 9 2014, 2:07 PM

mwalker: Can this be closed as RESOLVED FIXED, or is work left to do?

bzimport added a comment.Via ConduitJan 10 2014, 12:25 AM

mwalker wrote:

Looks like it's working in wmf10 (which is what deployed with it today.) So yes, marking as resolved fixed.

Aklapper added a project: Wikisource.Via WebMar 10 2015, 4:16 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.