Extension:TopicTags

Under Development

This works if installed as directed. But seeking feedback and improvements before release.

This page is also under development, and may contain errors or omissions.

=Introduction= This extension provides inline topic-tags, which are completely independent of Categories. Wiki editors can insert topic-tags inline anyplace on a wikipage. The new, unique feature of these topic-tags, is they are not just page-level tags. They can be scoped to specific locations within the body of a page.

Secret Sauce: Anchors
The secret sauce is anchors. Inline tags render as an HTML-anchor-- that makes it possible to link directly to the tag-location in the body of the wiki-page.

(Note this extension is unrelated to MediaWiki edit-tags)

=Appearance= Topic-tags have 2 formats:
 * Inline, where the tag is associated with a specific location on a page.
 * Page-level, where the tag is associated with an entire page.

For each tag, there's a Tag Page, containing a description of the tag, and a list of all pages containing the tag.

Inline Tags
An inline tag appears as a very small, super-script text-link. When clicked, reader is directed to the Tag-Page.

Page Tags
A page tag appears at the bottom of the page in full-size text. Also displayed are "Related Pages": a list of links to all other pages containing the same tag.

Tag Pages
For each tag, there's a Tag Page, containing a description of the tag, and a list of all pages containing the tag.

=Operation=

Clicking the tag-name in a tagged article
Test Click a tag-link to be directed to the Tag-Page.

Clicking a related-page link
Click a related-page link to be directed to a related wiki-page:
 * If the tag is inline on the related wiki-page, the reader will be directed to the specific tagged location in the body text.
 * If the tag is page-level tag on the related wiki-page, the reader will be directed to the top of the tagged page.

Creating Tags
To create a new tag:
 * 1) Browse to YOUR-WIKI-URL/Form:Tag
 * 2) Enter tag-name, and click "Create tag".
 * 3) Enter tag-description, and click "Save page".

Inserting Tags
Two topic-tag formats can be used in articles. The only difference is the trailing pipe | character. A tag-name may not contain an embedded space.

Inline Tags
Use the following syntax to create an inline tag. Displays as a small superscript in the article, with NO list of related articles. : 

Page Tags
Use the following syntax to create a page-level tag. Intended for bottom-of-article tags. Displays normal-size bold, with list of related articles: 

=Installation=

Done.
 * 1) Install all
 * 2) Create the.

Dependencies

 * Extension:Page_Forms
 * Extension:UrlGetParameters
 * Extension:DynamicPageList3
 * Extension:HTML_Tags
 * Extension:Labeled Section Transclusion

Extension Pages
To create these pages, you need only to paste in the wikitext provided at the links below:
 * New-Tag Form
 * Tag Template
 * Tag-list
 * /Template-Tag/Preload

=Implementation= The current version of this extension is php-free, and can be installed manually. FTP is needed to install the depended-extensions, but not needed to install any part of this extension.

Nested Transclusion
A topic tag is a tranclusion of the Template:Tag page 

That transclusion creates a secondary transclusion to Template:Tag. So the HTML that gets rendered on the tagged host-page is ultimately delivered by Template:Tag, even though the editor enters a transclude to Tag:Green or whatever.

Template:Tag
Template:Tag has multiple functions:
 * Transclusion: Return clickable HTML-links to tagged host-pages.
 * Display: Directly display related same-tag pages. (ie, the visitor views the Template:Tag page itself).

Transclusion
Inserted Topic-Tags are transclusions. When a host wiki-page contains the tag-code for Template:Tag, it passes a wiki-parameter to Template:Tag. This enables Template:Tag to return HTML to be rendered on the host page. For example, this inline tag-code on a wiki-page:  '''creates an HTML anchor on the host page. That anchor is the secret to inline-tags. '''The rendered HTML look like: CommonGround This page-level tag-code:  produces a list of related pages. That enables the user to jump directly to any related page: Tag:CommonGround <li> Portal:Welcome</a></li> <li> Openers</a></li> <li> Draft:You can't blame guns for socioeconomic problems.</a></li> <li> The U.S. does NOT have the world highest gun-homicide rate.</a></li></ul>

Notice the string "#Tag:" in each related-page link. That causes the link to go directly to the anchor-location in the body-text where the tag appears.

Display
When a tag-name is clicked in a tagged wiki-page, user is directed to Template:Tag. Template:Tag itself displays the tag-description and list of related pages. A Url parameter is used to pass the tag-name into the Template. That's the purpose of Extension:UrlGetParameters. Viewing a Template is atypical in MediaWiki, but works well for this purpose.

Tag Pages
Individual tag-pages exist for each tag-name, but the reader never sees them. They can be in a hidden namespace. Individual tag-pages have two functions:
 * to store the tag-descriptions. When Template:Tag is viewed for a particular tag, the tag-description is pulled from the individual tag-page.
 * to be a search-target for DPL.

DPL Format
The DPL3 format syntax is: | format=Startall,Start,End,Endall

In our DPL statement, the commas are placeholders for each format-tag (Startall,Start,End,Endall). In the example given, only one tag has data: the Start tag. Start represents the beginning of each article in the list.

The star resolves to a bullet in the output. https://help.gamepedia.com/DPL:Parameters:_Controlling_Output_Format#format

' To ensure links in the list go to those inline anchors, DPL must include pound-anchor in the links it outputs for found pages. ' Must output wikitext syntax for anchors: display_as ' https://meta.wikimedia.org/wiki/Help:Anchors ' DPL format is newline + found-page name linked to tag-anchor on found-page | format  = ,\n* %PAGE%,, }}

Note, if users use same tag in multiple locations on the page, then DPL anchor-links will go to the FIRST tag on the page.

=Release Version= I hope to achieve the following before publishing this extension:

Rationale
To allow tags to be auto-created the instant they are used. Currently, the NewTag form must be used to create a dedicated page for each new tag.

Other Benefits
Eliminating hard-coded tag-pages allows us to eliminate the Page_Forms dependency and others.

Progress
We're partway there. Template:Tag handles much of the heavy lifting for this extension. Through the use of parameters, this one page serves all named-tags. It generates:
 * Related-page lists
 * HTML for tagged host pages
 * Display of tag description

Blockers
To eliminate hard-coded tag-pages, 2 issues must be solved:
 * The pipe: List pages according to a transclusion parameter.
 * Data-storage: Store tag descriptions in a single table or page.

The pipe
To eliminate tag-pages, we'd want to transclude Template:Tag for all embedded-tags. Eg., <Green ></Green> instead of <undefined ></undefined>. For that to work, DPL (or API) would have to be able to tell the difference between <Green ></Green> and <Blue ></Blue> But DPL cannot tell the difference. It will count both as the same transclusion. DPL can't tell the difference, because DPL cannot see pipes. It can only find static pages. The tags inserted must transclude a specific page for DPL to find them (eg, <undefined ></undefined>. It can only tell the difference between <undefined ></undefined> and <undefined ></undefined> . So far, the MW API struggles with the pipe as well. No solution to this yet.
 * https://www.mediawiki.org/wiki/Topic:Ucmsdl9osvcbes0l
 * https://phabricator.wikimedia.org/T194039
 * Maybe can be achieved with wikitext, instead of DPL or API.

Storing Descriptions

 * The other purpose for tag-pages is to store tag-descriptions. To eliminate individual tag pages, we must find a way to store all tag-descriptions in a db table or a single wikipage. How to save a list of tag-descriptions in a single table or wiki-page? Some possible or rejected solutions:
 * Extension:Cargo: Rejected: Cargo is not appropriate for arbitrarily storing/retrieving individual records from a list.
 * Extension:ExternalData: Could be used to retrieve descriptions, but does not seem to offer a way to store individual records in a table or list. SemantcWiki is suggested
 * Extension:DataTable2: Unknown if feasible:
 * https://www.mediawiki.org/wiki/Topic:Udh53bn9qmovy1xd
 * https://www.mediawiki.org/wiki/Topic:Ud1kiswqh0cc1zsy
 * Custom PHP. But, to maintain our "php-free" goal, i'd make that a general purpose data-storage extension, separate from TopicTags.
 * No descriptions: A simple solution would be to eliminate tag-descriptions. That would get us closer to eliminating individual tag-pages. For a first release, i'm fine with that. Then we'd only have to solve the pipe problem. (However, in long-run, descriptions seem an essential feature for Topic-Tags.)

Solve

 * caching issues.
 * New-window issue.

Reduce dependencies

 * That would simplify installation and reduce footprint. But might not be possible, without writing some custom PHP.
 * Maybe we can bundle the dependencies into one installer.
 * Personal opinion: i believe everything this extension does should be doable without any extensions. I feel all behaviors are things that should be part of the MW core-- this extension isn't really doing anything groundbreaking. It all seems very consistent with core MW features. But it is what it is.
 * Extension:UrlGetParameters: Could be eliminated if MW supported page-parameters. But, feature rejected: https://phabricator.wikimedia.org/T194571

=Future Enhancements=
 * Stats: Would be cool to display usage stats, click stats, and other info about the tag on the Tag page.
 * There might be advantages to using separate tag-pages, as those pages might display statistics or other data more easily than the current dynamic template. Therefor, this can remain an option.

=PHP-Free Experiment= This project is an exploration into the feasibility of php-free extensions, which could be created by non-php programmers, using only wikitext.

Tentatively called "PHP-Free Extensions". A shorter name would be preferrable. Maybe "miniExt", "freelette", "pluglette", etc.

To facilitate non-programmer publishing of php-free extensions, there could be a generic installer, which registers the extension and creates needed pages.. Creation of extension pages could be automated with an API Import action.

Or, even better, the extension pages could themselves transclude model-pages from an external server, enabling extension developers to instantly roll-out improvements to any wiki which uses this extension.