Page MenuHomePhabricator

Exclude from print by category does not work any more
Closed, DeclinedPublic

Description

Author: mr.heat

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


Version: master
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45861
https://bugzilla.wikimedia.org/show_bug.cgi?id=50750
https://bugzilla.wikimedia.org/show_bug.cgi?id=48606

Details

Reference
bz48052

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:36 AM
bzimport added a project: Collection.
bzimport set Reference to bz48052.

PDF printing is extension "Collection" - moved

volker.haas wrote:

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.

mr.heat wrote:

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

mr.heat wrote:

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

ralf_wikimedia wrote:

That just insults other people. I'm pretty sure he didn't even look at that "pile of cruft".

mr.heat wrote:

(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. ***