Last modified: 2014-11-16 07:08:50 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 T15480, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13480 - Skip forced SUBST: for constant parser functions in user signatures
Skip forced SUBST: for constant parser functions in user signatures
Status: NEW
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Purodha Blissenbach
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-22 09:09 UTC by Purodha Blissenbach
Modified: 2014-11-16 07:08 UTC (History)
6 users (show)

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


Attachments

Description Purodha Blissenbach 2008-03-22 09:09:47 UTC
Currently, if you TYPE something like "([[User {{NS:1}}:myname]])" you GET "([[User {{SUBST:NS:1}}:myname]])" which does not work as intended.

There is no reason to deprieve users from making their own decision of wether or not they *mean* what they type. {{NS:1}} and {{SUBST:NS:1}} are quite different, especially when it comes to copying sections of talk from one wiki to another, or when you await an update of localization files (which would break all SUBSTed links at once)

If server load is a concern, and you really expect a majority of users to be either too lazy to subst, or NOT understand what they are doing, add another checkbox below "signature without automated link" which requests "do not automatically edit signature code" which is unchecked by default.
Comment 1 Robert Leverington 2008-03-23 19:56:19 UTC
All templates and parser functions (of which ns is) are substituted in signitures to reduce server load.  The user talk namespace will *alway* be accessible via User_talk regardless of localisation or configuration.  Suggest WONTFIX.
Comment 2 Purodha Blissenbach 2008-03-27 11:48:14 UTC
You did not understand the issue. It does not matter, whether or not you can access a NS via its canonical name. One of the points is what is being displayed. You don't want e.g. "User talk" displayed inside a chinese signature link, do you?

If server load is really a concern, and you really are expecting users not to have
enough understanding and awareness to use "subst" where appropriate, then, please, 
add a checkbox "do not automatically SUBST templates in signature code", and leave it unchecked by default. This checkbox need be available (and evaluated) ONLY if "signature without automated link" is arelady checkmarked. This should be a pretty small minority of all cases already.
Comment 3 Daniel Friesen 2008-03-28 05:46:56 UTC
No the issue is understood perfectly.

It's not a issue of users not understanding where to subst. Its that any use of templates inside of a Signature causes each and every page that the user signs to be added to the job que each and every time the template is edited.

Adding a checkbox and saying "please don't subst where inappropriate" isn't going to solve the issue, because substing anywhere at all is the core issue with server load, and allowing users' to chose to not subst just removes the entire point of autosubsting to prevent server load.
Comment 4 Purodha Blissenbach 2008-04-04 03:40:14 UTC
Apparently you did not understand the issue.

It's *not* about templates in the first place, it is about *constants*
like {{NS:x}} or {{PAGENAME}} etc., at least these are the problem.
They do *not* place anything in the job queue, since they are not
edited by anyone.

Adding a checkbox and saying "please don't subst where inappropriate" is
going to solve the issue.

Users can and will always add whatever they need (or want) manually, they
can subst a userspace page, to save typing, or do something else instead 
of signing, when signing ~~~~ does not produce the desired result. 
So forcing an automated subst where it is inappropriate will only make 
users lifes a little harder. Odds are, that they will hate programmers 
for it ;-)
So not solving this problem is not going to solve any problems. :-)

Btw. instances of signatures where subst is inappropriate should imho
be pretty rare, see above.
Comment 5 Daniel Friesen 2008-04-04 03:51:16 UTC
That checkbox may allow users to not subst constants. But it also allows them to bypass a core bit of code added for performance related to templates.

Users have a common tendency to want to transclude things rather than subst. And even though it harms the server, they'll do it even if you tell them not to.

So a checkbox will *not* be accepted as it allows users to bypass the performance security against what the sysadmin of the site has set to keep good performance of their wiki.


Now, give out a patch that will let the system differentiate between a constant and a template, and it may actually be accepted. But anything which allows users to bypass sysadmin settings and lower performance won't be accepted.
If Wikimedia were to enable the checkbox on it's wiki, you know users will start bypassing that performance security.
Comment 6 Purodha Blissenbach 2008-04-07 13:38:34 UTC
Are you aware that there is no point at all denying users the
ability to not use subst in their signatures?

Are you aware that users, who do not get what they need out of
~~~~, will simply type something else?

Are you aware that users can and will use any wikitext then,
be it with, or without subst?

So what the hell is keeping you from accepting a RARE special
case for those who most likely understand it? If the suggested
checkbox is not displayed unless someone disables auto-linking
their signatures, the vast majority of (uneducated) users will
never see it, leave alone checkmarking it.

I understand the grievance against template calls not subst'ed
and being inserted in lots of talk pages semiautomatically,
especially by "power users" who are likely to both use the
"don't subst" feature, and sign lots of contributions. The 
implied risk of a huge job queue, which btw., most likely 
would be of little use for the wikis original intent, is 
imho indebatable.

So I also understand the suggestion to make a distinction between
those {{'s signalling a constant, etc., and those ones of
something with the potential to fill the job queue.
I understand that likely noone might be interested in coding
it for me. Currently, I don't know how to make it, but I can
certainly find out.

How about generally not subst'ing constants? That avoids the
complication of adding a checkbox, but users likely would 
rarely type {{subst:some-constant}}, as you said, so this 
is also a  performance drawback during page rendering, 
is it not?

If you don't mind, I reopen this bug and take care of developing
a patch.


Comment 7 Niklas Laxström 2008-04-07 13:44:18 UTC
"([[User {{NS:1}}:myname]])" is so wrong. Why don't you use [[User talk:yourname|{{ns:user talk}}:yourname]]?
Comment 8 Brion Vibber 2008-04-07 21:08:55 UTC
Let's avoid a fight about exactly what sig format would be ideal. :)

I'm clarifying the summary for what's requested here. Please limit further comments to implementation details of how this might be accomplished (eg, whitelist or configuration marker or...)

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


Navigation
Links