A combination of things ruins the search for URL-style internal links that linksto does not rescue.
**Background**.
We can create URL-style internal links for a given pagename in a //generous //way,
that is space insensitive for the parser-function and the namespace:
- `canonicalurl:namespace: pagename`
- `canonicalurl:namespace:pagename`
- `canonicalurl: namespace:pagename`
- `canonicalurl: namespace: pagename`
and case insenstive for the parser-function and the namespace. Given a single fullpagename, there are fifteen ways that are significant to search patterns:
- `# `[{{canonicalUurl:nameSspace: pagename`
- `CANONICALURL:NAMESPACE: pagename`
- <snip many capitalizations that could exist>e}}]`
- `# `{{canonicalUurl:nameSspace: pagename`
But we can search for them in only a very specific way.pagename}}`
Its very specific for both phrase_search and "exact phrase".
For an "exact phrase" Search, its the colon : character.# `{{canonicalurl: namespace:pagename}}`
A non-spaced colon is no different from a letter# `{{canonicalurl:namespace: pagename}}`
for an exact phrase search.# `{{canonicalurl: namespace: pagename}}`
(The colon : character is otherwise, in Search as a whole, ignored.)
For a phrase_search, its the camelCase.# `[{{fullurl:namespace:pagename}}]`
If any of the words are camelCase, lowercase will not match them.# `[{{fullurl: namespace:pagename}}]`
The colon character is not a problem, it is ignored, but two# `[{{fullurl:namespace: pagename}}]`
words (or terms) connected by non-whit# `[{{fullurl: namespace non-alphanumeric characters: pagename}}]`
— there are two in this paragraph —# `[{{SERVER}}/{{localurl:namespace:pagename}}]`
are found in sequence and are sensitive to case.
For example if there is a `canonicalUrl:# `[{{SERVER}}/{{localurl: nameSspace:pageName` on the wiki, whatname}}]`
matches is# `[{{SERVER}}/{{localurl:namespace: pagename}}]`
- `canonicalUrl_nameSpace_pageName` (case sensitive, # `[{{SERVER}}/{{localurl: namespace insensitive): pagename}}]`
- `canonicalUrl_NameSpace_PageName` (case sensitive, # `[{{SERVER}}/wiki/namespace insensitive):pagename]`
- `"# (Fullurl and canonicalurl:namespace:pagename"` (case insensitive, space sensitive also accept a parameterized-call form.)
But that target can link with many more capitalization and spacingwe can search for them in only an //ungenerous// way. For these link constructs, Search is narrow and specific. Insource is the only option (without a genuine linksto parameter), because page visibility of the sought construct is, although possible, not likely. Even if they were in a page-visible in form, Search is camelCase sensitive, but namespace names and parser functions are fully accepting of any camelCase.
If this is true, then, (since spacing has fewer variables)**The nature of CirrusSearch colon : character**
For an "exact phrase" search the non-spaced colon is no different from a letter or a number. If there is a space after it, the alternative without the space will not match. If this is true, then it takes well over eighteen searches to hunt for "what links here":to a page:
# `insource: "canonicalurl:namespace:pagename"`
# `insource: "canonicalurl:namespace_alias _1:pagename"`
# `insource: "canonicalurl:namespace_alias _2:pagename"`
# `insource: "canonicalurl namespace:pagename"`
# `insource: "canonicalurl :namespace_alias _1: pagename"`
# `insource: "canonicalurl namespace_alias _2: pagename"`
# `insource: "fulurl:namespace:pagename"`
# `insource: "fulurl:namespace_alias _1:pagename"`
# `insource: "fulurl:namespace_alias _2:pagename"`
# `insource: "fulurl namespace:pagename"`
# `insource: "fulurl namespace_alias _1:pagename"`
# `insource: "fulurl namespace_alias _2:pagename"`
# `insource: "fulurl:namespace::namespace pagename"`
# `insource: "server locafulurl: namespace: pagename"` (plus any namespace alias)
# `insource: "server localurl :namespace:pagename"` (plus any namespace alias)
# `insource: "server wikilocalurl namespace:pagename"` (plus any namespace alias)
# `insource:"https SERVER wiki "server localurl:namespace: pagename"` (plus any namespace alias)
# `insource:"https SERVER "server localurl: namespace: pagename"` (plus any namespace
alias)# `insource:"server wiki namespace:pagename"`
To make Search matters worse
* These many searches don't prove a link — `[{{fullurl:...]` or `https:{{SERVER}}` or `canonicalur:{{SERVER}}` — but are the best "probable links" to a page, or best "pattern to investigate".
* These many searches don't include the possibility of `{{anchorencode}}` and `{{urlencode}}`. And the parameterized calls that fullurl, canonicalurl, urlencode can make.
* Linksearch and its MediaWiki extension are obsoleted.
* Insource doesn't take OR.link-search matters worse:
* Regex has no filter to accompany it for this instance. Name one. Linksto cannot be used for a filter for regex because linksto does not recognize URL-style links.
(Linksto? Linksto reports every kind of namespace in one search, yeah! (ButA namespace with two aliases adds 26 more searches.
only wikilinks* You really need yet another variable, a /regex/ just to look for the opening [ bracket. It would need to accompany each one in its own distinct, not redirect links or URL-style links.unique form. Yet //still// it could not prove a closing ] bracket existed, WHL reports every kind of link in every way to ''the content'' of a page ''not just a name of a page''.)
One small case in one point: the valid link pattern `fullurl:nonaNS:pagename`,because the dot . metacharacter represents any character //including a newline//.)
and some valid-link-pattern searches:
- [[//en.wikipedia.org/wiki/index.php?title=Special:Search&search=notaNS+prefix:user:cpiral/sandbox|nonaNS]] (works)
- [[//en.wikipedia.org/wiki/index.php?title=Special:Search&search=notans+prefix:user:cpiral/sandbox|nonans]]
- [[//en.wikipedia.org/wiki/index.php?title=Special:Search&search="fullurl:+notaNS:pagename"+prefix:user:cpiral/sandbox|"fullurl: notaNS:pagename"]]
- [[//en.wikipedia.org/wiki/index.php?title=Special:Search&search="fullurl:+notaNS:+pagename"+prefix:user:cpiral/sandbox|"fullurl: nonaNS: pagename"]]
- [[//en.wikipedia.org/wiki/index.php?title=Special:Search&search="fullurl:nonaNS:+pagename"+prefix:user:cpiral/sandbox|"fullurl:notaNS: pagename]]
* These many searches don't include the possibility of finding the parameterized, URL-style, internal wikilinks, where `{{anchorencode}}` and `{{urlencode}}` often come in to play the difficult, probability, "sequences" game we're forced to play.
* [[//mediawiki.org/wiki/extension:LinkSearch|Extension LinkSearch]] is heavily deprecated and basically obsolete. The [[//en.wikipedia.org/wiki/Wikipedia:WikiProject_Check_Wikipedia/List_of_errors| Wikicheck ]] mentions URL-style internal wikilinks as error 90, "Internal link written as an external link"Template:Linksearch| linksearch template on Wikipedia]] hasn't been touched in years.
No bots fix them, but they are found and listed* Insource doesn't take OR.
[[//en.wikipedia.org/wiki/Template:srlink|Srlink]] makes them for self-referencing purposes so mirrors can link to wWikipedia:WikiProject_Check_Wikipedia/List_of_errors| Wikicheck ]] mentions URL-style internal wikilinks as error 90, "Internal link written as an external link". No bots fix them, but they are found and listed for cleanup, and yet templates like [[//en.wikipedia.org/wiki/Template:srlink|Srlink]] produce them, so that for example, mirrors can back link to Wikipedia in certain cases.