Last modified: 2014-02-19 15:35:12 UTC
The "Exclude in print" feature in the Wikipedia projects stopped to work. For example http://en.wikipedia.org/wiki/MediaWiki:Coll-exclusion_category_title refers to http://en.wikipedia.org/wiki/Category:Exclude_in_print Every template in this category should be excluded from all "Print/export" functions: "Create a book", "Download as PDF" and "Printable version". This worked for years as far as I know. Now it does not work any more. I tested it in the German and the English Wikipedia. For example text from this template was not exported to PDF before but is now: http://de.wikipedia.org/wiki/Vorlage_Diskussion:ImDruckVerbergen Please don't confuse this with the "noprint" CSS class. This is an other way to exclude stuff from print. If you think this is a bug in a MediaWiki extension please move the report.
PDF printing is extension "Collection" - moved
See also bug 45861 comment 12 and the following links: 1) https://www.mediawiki.org/wiki/Thread:Extension_talk:Collection/Hide_in_print_broken 2) https://en.wikipedia.org/wiki/User:Unjedai/Hide_in_print_test 3) https://en.wikipedia.org/wiki/Template_talk:Hide_in_print#Possible_Fix
See https://bugzilla.wikimedia.org/show_bug.cgi?id=50750 for the required change in css and the mailinglist entry for the complete description of the work-around: https://groups.google.com/d/msg/mwlib/mdiqIWwH3RQ/58CP-3-cYZIJ
Change 94954 had a related patch set uploaded by MaxSem: Remove template blacklisting functionality https://gerrit.wikimedia.org/r/94954
We're deprecating the old mwlib-based renderer completely, hence we're not touching it with a mile-long stick. The new renderer will be based on Parsoid (or the old PHP parser for now if there will be technical difficulties) and thus will not have a custom renderer that would ban templates. And this is a good thing because long template lists is not a maintainable solution. Instead, we will stick to print CSS.
(In reply to comment #5) > long template lists is not a maintainable solution. What do you mean with "maintainable"? You don't have to maintain the category. It's maintained by the community members. You can simply use what's in the category. > we will stick to print CSS. It's true that we can use class="noprint" in many cases. So we did in the past. But sometimes it's required to deliver a completely different output to the PDF export. One example is a template that generates pie charts made with CSS rounded borders. I'm sure this will not be supported for a long time by the PDF export, if ever. What's your proposed solution for these now broken cases? To always output duplicate content everywhere (one with class="noprint" and one with something like class="onlyprint") is not an adequate solution, in my opinion.
(In reply to comment #6) > (In reply to comment #5) > > long template lists is not a maintainable solution. > > What do you mean with "maintainable"? You don't have to maintain the > category. To support this "minor feature" you need either keep lots of hacks to parser or have a completely different parser. > It's maintained by the community members. You can simply use what's in the > category. While there are far more community members than developers, please have mercy on editors, they have much more important things to do than maintain a pile of cruft needed only to a minor share of our visitors. > > we will stick to print CSS. > > It's true that we can use class="noprint" in many cases. So we did in the > past. > But sometimes it's required to deliver a completely different output to the > PDF > export. One example is a template that generates pie charts made with CSS > rounded borders. I'm sure this will not be supported for a long time by the > PDF > export, if ever. We're working on using WebKit for rendering, it supports everything a normal browser does. > What's your proposed solution for these now broken cases? To always output > duplicate content everywhere (one with class="noprint" and one with something > like class="onlyprint") is not an adequate solution, in my opinion. That's not a proposed solution, that's a solution actively being worked on and going live quite soon.
(In reply to comment #7) > keep lots of hacks Are you sure we are talking about the same thing? It's simple: Treat a bunch of templates like they are empty. Use /Print sub-templates if they exist. Done. > pile of cruft I'm sorry? You call providing readable PDF files what? If you don't think what you do is important why are you working on it? > solution actively being worked on and going live quite soon. After the feature set was dropped 8 months ago. Excuse me if I'm not in the mood to feel thankful. If your replacement for a dropped feature is to deliver duplicate content to search engines and every reader of the regular and mobile web sites it's simply not an adequate solution.
(In reply to comment #8) > I'm sorry? You call providing readable PDF files what? Please stick to things instead of persons. Max did not call "providing readable PDF files" a "pile of cruft", but THE CURRENT CODE which provides the functionality to convert wikipages to PDF files.
Clarification: I probably shouldn't speak for Max here as I cannot read his brain, but that's my interpretation. "Assume people mean well." is helpful.
That just insults other people. I'm pretty sure he didn't even look at that "pile of cruft".
(In reply to comment #7) > editors [...] have much more important things to do than maintain a pile of > cruft needed only to a minor share of our visitors. My interpretation is that he is referring to editors like me that spent their time on maintaining the exclusion category and creating print sub-templates to provide well readable PDF files. All we did became a "pile of cruft" 8 months ago. (In reply to comment #10) > "Assume people mean well." is helpful. So did I when I maintained the exclusion category and created print sub-templates.
*** Bug 59667 has been marked as a duplicate of this bug. ***
