Page MenuHomePhabricator

Request: Allow passing parameters to MediaWiki Pages
Closed, DeclinedPublic

Description

Parameterized wiki pages

This thread concerns parameterized wiki pages.

Use-case
The use-case for parameterized internal wiki links is the ability to display a wiki-page with dynamic behaviors or values based on the parameters passed in from the linking page. For example, (assuming hypothetically that broken pipe ¦ could be used to delimit parameters in an internal link), the internal link:

[[Fruit¦apples]]

would display a wiki page called Fruit, and pass to it the parameter "Apples". If the page Fruit contained:

I like {{{1}}}.

This would render as:

I like apples.

I believe many wikis would find this a very useful, powerful feature.

Transclusion parameters

It's appropriate to say development of this feature is already half done. Page-parameters completes the feature set begun by transclusion-parameters. It's an inconsistency of MediaWiki that parameterized transclusion is available, but not parameterized links.

The feature requested in this post, wiki-page parameters, is basically the same behavior as Transclusion parameters: passing parameters to another wikipage. But, unlike transclusion, this request is to pass variable values to a displayed wikipage (directly rendered), rather than a transcluded wikipage.

Currently, Templates support parameters for transclusion. (actually, all wiki-pages support transclusion and transclusion-parameters, but Template is the namespace intended for transclusion).

"To enrich the mechanism of transclusion, MediaWiki allows parameters to be passed to a template when it is transcluded. Parameters allow the template to produce different contents or have different behaviors."

Parameters can be sent to a transcluded page via curly-braces transclusion, with pipe as delimiter. Example of a call to a parameterized MediaWiki template:

{{Thankyou|all your efforts|Me}}

For more info, you may review the following resources:
https://www.mediawiki.org/wiki/Help:Templates#Parameters
https://www.google.com/search?q=mediawiki+transclusion+parameters&tbs=li:1

Parameterized web pages

The feature requested in this post, wiki-page parameters, is similar to Parameterized web pages: The ability to pass variable values to a page on the internet:

URL parameter: A way to pass information about a click through its URL. You can insert URL parameters into your URLs so that your URLs track information about a click. URL parameters are made of a key and a value separated by an equals sign (=)."
https://www.google.com/search?q=%22URL+parameters%22&tbs=li:1

The pervasiveness of parameterized webpages is another good argument in support of parameterized links. The usefulness of parameterized-webpages also applies to wiki pages.

Example of a url parameter is everything after the question mark in this url:
https://www.mediawiki.org/w/index.php?title=Topic:Ucmsdl9osvcbes0l

Except in this request, we're passing parameters to internal wiki-pages specifically, rather than to just any webpage. For that reason, we want use internal MediaWiki syntax.

Redirects

A redirect example isn't critical to understanding this thread. It's just an example of where one might apply a parameterized internal link.

Like ANY page with a redirect, you'll be redirected to the page specified in the redirect. That's the point of a redirect-- it redirects the visitor to a different page. Except (if internal link parameters were supported), the parameters would get passed to the linked page. That means, when the page is redirected, the target page would receive whatever parameters are sent to it from the originating page. In this example, the string "Apples" would be a parameter passed to the page Fruit (IF link-parameters were supported with broken pipe ¦, which they aren't currently):

#REDIRECT [[Fruit¦Apples]]

MediaWiki Design Flaws

Ideally, this would be implemented with square-bracket internal-link style, because that's MW's internal link syntax. Ideally, imo, new features should conform to existing implementation, instead of adding yet another different syntax.

@Aklapper wrote: [[Fruit|Apples]] is existing syntax to make the string "Apples" link to the page "Fruit".

You're absolutely right, and therein is a glaring inconsistency in MW:

  • With transclusion, the pipe means: parameter: {{Thankyou|all your effort}}
  • With internal links, the pipe means: link-text. [[Fruit|Apples]]
  • With external links, a space means: link-text. [https://mediawiki.org MediaWiki]

https://www.mediawiki.org/wiki/Help:Links

The MW developers chose to give pipe two different meanings depending on type of link, and they require two different syntaxes to display link-text. That's confusing and inconsistent-- extremely, excruciatingly poor design, imo.

It also means we can't identify parameters with pipes, as we do in transclusion, because, with double-square internal links, the pipe indicates display text. Thus, due to a disorganized link-syntax, pipe cannot be used in a consistent way.

Solutions

So, our next option is to introduce a new syntax.

This new syntax mustn't conflict with existing double-square links. The double-square with pipe is already used in all existing MW installs, and we don't want to break existing wikis by changing existing syntax.

What syntax would support internal link parameters without breaking existing wikis? There are a few possible solutions:

Best solution:

  • [Namespace:Page|Param1|Param2 Display]
    • Syntax:
      • Don't touch double square bracket. Double square internal links will continue to work as now.
      • Single square external links will continue to work as now.
      • Use single squares (same as external-link syntax).
      • Use pipes for all params (same as transclusion).
      • And use whitespace for display text (same as external-link syntax).
    • Benefits:
      • Consistent parameter syntax for transclusion and linking,
      • Consistent bracket style and display-syntax for internal and external links.
      • Won't break existing wiki links.
      • Existing wikis WOULD be able to use this new feature.
      • Less typing.
      • Can reuse existing code:
        • Entry point for single square links.
        • Validate that the page name is valid.
        • Interpret display text.
        • Apply parameters.
    • Dev notes:
      • Modify existing external link code seems least effort, since this new syntax is based on external link syntax.
      • A design that can accommodate new link-types in the future would use case statements at the single square entry point:

What kind of link is it?

  • internal: handle internal link
  • external: handle external link
  • transwiki: handle transwiki
  • future type: handle future type
  • none of the above: return error
      • I propose link-type tags with # sign. Eg:

[#internallink: Namespace:Page|Param1|Param2 Display]

        • Such link-type tags with # sign would enable an unlimited number of link types.
        • Eliminates need for string-evaluation of the link, like "Is there www?"
        • Can make internal link the default, so can leave out for internal links.
        • Later, could add support for abbreviations.

Acceptable solution:

  • Use current double-square internal-link syntax, and place parameters after the display-text. All subsequent pipes assumed to be parameters: [[PageName|Display|Param1|Param2]] -This is a decent short-term option. It retains solution-brackets for internal links, would not break existing wikis, and would still allow pipe as parameter delimiter. Will allow existing wikis to use the new feature. Less dev effort than 'Best' solution above, because retains double-squares (no new internal/external test needed). However, retains MW's inconsistent syntax, and doesn't support future link types.

Unacceptable solutions:

  • [[Namespace:Pagename|Param1 Display]] Break existing Wikis by redefining double-square internal link syntax. Provide config option to enable EITHER/OR. Use double-square internal-link syntax. All pipes, including first one, are parameters (same as transclusion). Use whitespace at the end to indicate display text (same as external links). - But if implemented now, it would break links on all existing wikis, which is not acceptable. To fix that, we could offer a config option that toggles whether to interpret pipe as parameter-delimiter (the new feature), or as display-text (the current standard). New wikis could then take advantage of the feature, without breaking existing wikis. More dev effort than 'Preferred' solution above, cuz requires a new config option in user Prefs or in LocalSettings.php. Existing wikis would NOT be able to use the new feature.
  • Use pipe-escape as parameter delimiter: {{!}} -Too much typing. Misuse of escape.
  • Require underscore for name, so space can mean show, thus freeing up pipe for params: [[pg_name show-string|param1|param2]] -Not consistent with existing link-rules, which currently allow white-space.
  • Use questionmark+ampersand (like url parameters): [[MyPage?MyParam=MyValue|Display]] -Not consistent, doesn't look like wikitext, seems like a crappy workaround.
  • Use broken pipe ¦ . [[Namespace:Page|Display¦Param1¦Param2]] -Not on keyboard.
  • Use double pipes: [[Namespace:Page|Display||Param1||Param2]] -Too much typing.
  • Use triple squares for parameterized internal links, and whitespace for display text (consistent with external links): [[[Namespace:Page|Param1|Param2 Display]]] -too much typing, and Introduces a new syntax, instead of building on existing syntax.
  • Place parameters before the page-name: [[Param1|Param2|Namespace:Page|Display]] -Counter-intuitive.

*Alternatives*

Extension:UrlGetParameters provides a workaround, but there are problems with that:

  • only works with "a" tag HTML links, not wikitext square bracket links. So it's inconsistent with MW standard linking.
  • parameters can't be queried with standard MW syntax, eg {{{1}}} etc. Must use #urlget.
  • doesn't work at all with #REDIRECT.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 12 2018, 2:12 PM
Aklapper changed the task status from Open to Stalled.EditedMay 12 2018, 3:29 PM
Aklapper added a project: MediaWiki-Redirects.

Please provide a use case when requesting features. When would you want to put #REDIRECT [[Template:Fruit|Apples]] on a wiki page and why?

Johnywhy added a comment.EditedMay 12 2018, 11:21 PM

comments added to OP.

Johnywhy updated the task description. (Show Details)May 12 2018, 11:22 PM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 12 2018, 11:28 PM
Johnywhy updated the task description. (Show Details)May 12 2018, 11:34 PM
Johnywhy updated the task description. (Show Details)May 12 2018, 11:57 PM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 13 2018, 12:02 AM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 13 2018, 12:06 AM
Johnywhy updated the task description. (Show Details)May 13 2018, 12:09 AM
Johnywhy updated the task description. (Show Details)May 13 2018, 12:13 AM
Johnywhy changed the task status from Stalled to Open.May 13 2018, 12:19 AM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 13 2018, 12:22 AM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 13 2018, 1:30 AM

Reading the task description I unfortunately still have no idea what "parameterized websites" are in this context. Or "parameterized links".
(Google Search gave me 218 results for "parameterized website" but no definition.)
The UrlGetParameters extension allows using and displaying URL parameters on a wiki page via a parser function ({{ }}).

Example Use Cases:

  • #REDIRECT with parameters.

If a MediaWiki page had #REDIRECT [[Fruit|Apples]] as its only content, what exactly would happen if I visited that page? Where would I end up? [[Fruit|Apples]] is existing syntax to make the string "Apples" link to the page "Fruit". I don't see sense in combining this link syntax with a #REDIRECT?

This comment was removed by Johnywhy.
Johnywhy renamed this task from Request: Enable Url Parameters with Internal Link Syntax to Request: Enable Page Parameters with Internal Link Syntax.May 26 2018, 7:46 AM
Aklapper renamed this task from Request: Enable Page Parameters with Internal Link Syntax to Request: Allow passing a URL parameter to be used within the internal link syntax on that page.May 26 2018, 1:10 PM
Johnywhy added a comment.EditedMay 26 2018, 6:32 PM

Pages, Not Sites

Reading the task description I unfortunately still have no idea what "parameterized websites" are. Google Search gave me 218 results for "parameterized website" but no definition.

Apparently, you misread my description. I wrote "parameterized web pages", not parameterized "websites". It should be clear from the context of my description, that a "parameterized webpage" is a webpage with parameters. Web devs will understand that means "url parameters".

Only content

@Aklapper wrote: If a MediaWiki page had #REDIRECT [[Fruit|Apples]] as its only content, , what exactly would happen if I visited that page? I don't see sense in combining this link syntax with a #REDIRECT?

Apparently, you misread my description. I did not say it's the "only" content.

Task title

@Aklapper , Regarding your name-change of this task to "Allow URL Parameters..."

Calling this feature-request "url parameter" is not correct, nor is it accepted MW terminology.

Apparently, you misread my post (i'm sensing a pattern here). Or you don't understand the concepts.

I mentioned URL parameter simply because it's a similar concept. In web dev, a URL parameter consists of a question mark attached to the entire url. Eg:

https://www.mediawiki.org/w/index.php**?title=Topic:Ucmsdl9osvcbes0l**

But for this feature-request, it's appropriate to use MediaWiki terminology. And to use correct terminology. "URL Parameter" is neither.

"URL parameter" is not MediaWiki terminology. Nowhere in transclusion doc are parameters referred to as "URL parameters". https://www.mediawiki.org/wiki/Help:Templates#Parameters

"URL parameter" is incorrect, because there is no URL with an internal link.

I removed "internal link syntax" from the title, because my proposed solution uses external, not internal, link syntax.

@Aklapper , you have a pattern of misreading, or misunderstanding, my posts. If possible, please refrain from commenting on, or acting on, my posts. Please leave it to others to do so. I assume you're not the only person here.

Johnywhy renamed this task from Request: Allow passing a URL parameter to be used within the internal link syntax on that page to Request: Allow passing a MediaWiki parameter in the internal link syntax.May 26 2018, 6:38 PM
Johnywhy renamed this task from Request: Allow passing a MediaWiki parameter in the internal link syntax to Request: Allow passing MediaWiki parameters in the internal link syntax.May 26 2018, 8:30 PM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 26 2018, 8:32 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 2:14 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:02 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:06 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:26 PM
Johnywhy renamed this task from Request: Allow passing MediaWiki parameters in the internal link syntax to Request: Allow passing parameters to MediaWiki Pages.May 27 2018, 3:29 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:39 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:41 PM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 27 2018, 3:46 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:52 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:55 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 3:58 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:06 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:19 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:21 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:24 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:32 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:39 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 4:52 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 5:22 PM
Johnywhy updated the task description. (Show Details)
Johnywhy updated the task description. (Show Details)May 27 2018, 5:26 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 5:35 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 5:37 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 5:54 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 5:58 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 6:00 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 6:02 PM
Johnywhy updated the task description. (Show Details)May 27 2018, 6:04 PM

(Would you please prepare task description changes locally and once done add them here in one edit, to not create gazillions of "Johnywhy updated the task description. (Show Details)" entries which make the discussion in this task harder to read because of all the required scrolling? Thanks for considering.)

Johnywhy added a comment.EditedMay 27 2018, 9:29 PM

i agree those "updated the task description. (Show Details)" alerts are totally annoying. Can we turn them off?

i'll try to make changes locally first. But that's hard, cuz i improve my posts frequently, and i want the public version to be the latest and greatest.

you can get relief by adding the following to your phabricator CSS:

.phui-timeline-minor-event, .phui-timeline-spacer{
display:none;
}

Johnywhy updated the task description. (Show Details)May 28 2018, 1:55 AM
Legoktm closed this task as Declined.May 28 2018, 2:21 AM
Legoktm added a subscriber: Legoktm.

This isn't going to be implemented in the MediaWiki parser, because varying on URL parameters would cause caching problems. Your best bet is to use the https://www.mediawiki.org/wiki/Extension:UrlGetParameters extension that you mentioned in the task description.

Johnywhy updated the task description. (Show Details)May 28 2018, 2:23 AM
Johnywhy updated the task description. (Show Details)May 28 2018, 2:28 AM
Johnywhy updated the task description. (Show Details)May 28 2018, 2:31 AM
Johnywhy added a comment.EditedMay 28 2018, 2:34 AM

varying on URL parameters would cause caching problems.

It's correct that a parameterized page could not be cached the way a static page can be cached.

  • The same is true of parameterized transclusion, correct?
  • And we accept that with transclusion because of the benefits parameters provide, correct?

varying on URL parameters would cause caching problems.

It's correct that a parameterized page could not be cached the way a static page can be cached.

  • The same is true of parameterized transclusion, correct?

No, pages that have parameterized templates can be safely cached.

Johnywhy added a comment.EditedMay 28 2018, 2:36 AM

pages that have parameterized templates can be safely cached.

But the transcluded region cannot be cached.

pages that have parameterized templates can be safely cached.

But the transcluded region cannot be cached.

Sure it can. Most pages on Wikipedia use parameterized templates and are cached in Varnish.

Sure it can. Most pages on Wikipedia use parameterized templates and are cached in Varnish.

How can a parameterized template be cached, when it will display differently every time?

Sure it can. Most pages on Wikipedia use parameterized templates and are cached in Varnish.

How can a parameterized template be cached, when it will display differently every time?

The template itself is not being cached, the output of the whole page is. MediaWiki renders the page, pulling in templates as necessary. At this point, all of the inputs to the templates involved are in the page's wikitext itself, or in one of the page's dependencies that are all tracked. If the page or its dependencies change, the cache is invalidated, and reparsed on demand as needed.

What you're asking for is to allow arbitrary URL parameters be used as inputs to wiki content, which is impossible to cache since the contents are, arbitrary. If caching isn't important for your wiki, the aforementioned extension will probably work.

Johnywhy added a comment.EditedMay 28 2018, 10:02 AM

Wiki designers would use this feature with the understanding that the trade-off for the power of parameters is that the page won't be cached--

Same as any parameterized webpage. People visit uncacheable parameterized webpages every day by the gazillions.

This isn't going to be implemented in the MediaWiki parser, because varying on URL parameters would cause caching problems.

@Legoktm, This feature will not "cause problems with caching" as you stated-- the page simply wouldn't be cached. All other pages will still be cached normally.

In addition, if the page doesn't contain any parameters, then the page can be cached normally. It's a normal page.

In the short term, the benefits of parameterization far outweigh the loss of caching.

Caching itself can cause problems. For example, I've yet to find a way to keep CategoryTree updated when pages are deleted. Clearing the cache doesn't fix it.

Long-term, special Caching mechanisms might be developed for this feature, such as caching all of the page except the parameterized text, or generating a separate cache for each caller.

The benefits include more than just parameters. Even if parameters were eliminated from this feature, it still provides a vital improvement to MW: consistent linking syntax, instead of the mess we have now.

@Legoktm, I'm proposing this as a core feature, not an extension. Presumably anyone is free to develop and publish an extension without seeking approval here, correct?

use the https://www.mediawiki.org/wiki/Extension:UrlGetParameters extension that you mentioned in the task description.

Won't Extension:UrlGetParameters also prevent caching? You are recommending an alternative which suffers from the same problem as the problem for which you declined this request-- no caching. In any case, I cannot use it due to the problems i mentioned in the task description.

You are recommending an alternative which suffers from the same problem as the problem for which you declined this request

See T194571#4235336. In short, this isn't going to be implemented in the MediaWiki parser. (Might be that the costs outweigh the benefits.)

Vvjjkkii renamed this task from Request: Allow passing parameters to MediaWiki Pages to k2caaaaaaa.Jul 1 2018, 1:10 AM
Vvjjkkii reopened this task as Open.
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from k2caaaaaaa to Request: Allow passing parameters to MediaWiki Pages.Jul 2 2018, 4:16 PM
CommunityTechBot closed this task as Declined.
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.