Page MenuHomePhabricator

Show full template call, rather than a link to the template page, when the expansion size limit is tripped
Open, LowPublic

Description

Author: folengo

Description:
On the following test page :

:fr:Utilisateur:Teofilo/test1

http://tinyurl.com/mhedy

I call ten times the same template {{D-2 MONTHNAME}} which is a template
displaying (in French) the month name of two days ago.

You can notice that the first 5 template calls are OK, while the following 5
calls result in errors.

The French Wikipedia's village pump ("Le Bistro")'s main page which uses several
templates is currently brokendown, and I guess this failure is linked to the
above mentioned problem.


Version: unspecified
Severity: normal
URL: http://fr.wikipedia.org/wiki/Utilisateur:Teofilo/test1

Details

Reference
bz7005

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:22 PM
bzimport set Reference to bz7005.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

Take a look at the source; several instances of "<!-- WARNING: template omitted,
pre-expand include size too large -->". Your template length is tripping the
parser's detection of mass-inclusion.

folengo wrote:

What do you mean by "the source" ? Could you give me the URL please ?

When I click on the "edit" tab, I cannot see any warning such as that which you
are quoting.

How comes that everything has been OK for 2 months, not to say 6 months, until
today or yesterday, and suddenly these templates can no longer be used properly?

Have some new restrictions been enacted today or yesterday ?

rotemliss wrote:

(In reply to comment #2)

What do you mean by "the source" ? Could you give me the URL please ?

The source of the HTML page.

folengo wrote:

This is just to say that I have found the warnings (in the HTML source as you
said, not in the edit tab, because the template is not "substed")(Thanks Rotem
Liss for the explanation).

So my only question remains : have some new restrictions been implemented
recently, because apparently everything was OK on the French village pump until
yesterday or this morning.

robchur wrote:

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

robchur wrote:

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

ayg wrote:

(In reply to comment #4)

So my only question remains : have some new restrictions been implemented
recently

Yes. Tim said on IRC that some of the really large templates were causing
ten-second latency in some cases; things were getting out of hand with
ParserFunctions being used in insanely complicated configurations for stuff like
date functions.

folengo wrote:

Is living in a time zone different from that of London (Greenwich Meridian Time)
an "insanely complicated configuration" ?

Or can you tell me how to implement easily a template providing a {{CURRENTDAY}}
variable changing at midnight not GMT, but CEST (Central European Summer Time) ?

see bug 366 for {{CURRENTDAY}} and time zones.

That would be {{LOCALTIME}}, which is not yet implemented I
think.

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

Fixed Le Bistro, fixed [[:fr:Utilisateur:Teofilo/test1]]. Mostly fixed
through the introduction of {{CURRENTHOUR}}, to replace that huge #switch
statement to extract the hour from {{CURRENTTIME}}. Moving template
documentation to a subpage also helps a bit.

(In reply to comment #7)

(In reply to comment #4)

So my only question remains : have some new restrictions been implemented
recently

Yes. Tim said on IRC that some of the really large templates were causing
ten-second latency in some cases; things were getting out of hand with
ParserFunctions being used in insanely complicated configurations for stuff like
date functions.

I don't mind ParserFunctions being used for dates, that was one of the motivating
applications. The applications I've seen today which I object to are:

  1. using templates as huge pseudo-databases, e.g. with #switch. MediaWiki is not a

DBMS. Maybe some day it will be, with with Wikidata, but currently it is extremely
inefficient to use it in this way. Sorry, but you'll just have to update every page
that uses the data, every time the data is changed.

  1. Using MediaWiki as a scripting language to generate repetitive content on a

single page. Since MediaWiki is not a scripting language, the templates used tend to
be very esoteric. Thus, the generated content is very hard for non-technical users
to edit. [[:ksh:Wikipedia:Babel]] was a prime example of this. In addition to
incomprehensibility, it was also inefficient. It expanded to thousands of HTML
comments, megabytes of redundant and useless text which the parser had to process on
every cache miss.

I expect that most broken articles can be fixed by applying
[[Special:ExpandTemplates]].

folengo wrote:

Tim Starling, you are wonderful !

robchur wrote:

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

robchur wrote:

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

robchur wrote:

Reopening this and duping all the others here; reopening in case something
further needs doing in bulk, although from comments here and elsewhere, I doubt
it. These issues will need to be corrected on a case-by-case basis.

It seems "skipped" template expansions are now rendered as links - i.e. {{Foo}}
renders like [[Foo]]. This makes no sense at all. At *least* it should render
like [[Template:Foo]], but I don't think the link is helpful anyway.

Someone suggested that the fully unexpanded text should be show, including all
parameters. I agree with that - itwould be much more obvious what's going on,
and the result would still be intelligable, if not pretty.

RSYQFIOJGWZA wrote:

I also think the fully unexpanded text should be shown, including all parameters. This would aid greatly in troubleshooting.

RSYQFIOJGWZA wrote:

Perhaps there could be a preference "Format links to non-existent templates {{like this|first|second|third}} (alternative: {{like this}})" under "Appearance / Advanced options" that defaults to unchecked (and can be checked for those of us who wish to fix templates and calls to them).

Also, perhaps there could be a preference "Prompt me when entering a redlink" under "Editing / Advanced options" that defaults to checked (and can be unchecked for those who regularly add redlinks).