This generates lists of links based on page namespaces. It used to be in wider use as the wiki was developed, and it works well. However, a different, tag-based approach with the Tag plugin gradually came to be preferred.
The primary advantage of using this (or Tag) to make lists is that they are dynamic. As pages are added to the wiki, items are added to the appropriate lists automatically. This saves having to remember all the places that pages like a new one have been linked and having to add links to them manually. Neither, alas, can be used with the Navigation plugin, however.
Here are a few places where the plugin is still used in the wiki. They serve to illustrate just a few of the options available.
The plugin is used to create the All works, alphabetized listing. That style of multi-column, labelled listing is produced in this way.
<nspages -h1 -sortId -textPages="" -r -exclude -exclude:[start navbar rightsidebar by_creation_date publishers:]>
Here is what the different settings do.
-h1 | Display the first heading on each page in the list. |
-sortId | Sort the list by the page names, without namespaces. |
-textPages | Suppress the list title by making it a blank string, “”. |
-r | Look recursively through all sub-namespaces of the current one. |
-exclude | Exclude the current page from the listing. |
-exclude:[…] | Exclude the pages between the brackets from the listing. |
The main credits page is similar, but it is sorted by the heading values rather than the page names. The former are written last-name-first while the latter are not.
<nspages -h1 -textPages="" -exclude -exclude:[ambiguous_names some_person c_template a_c d_g h_k l_o p_s t_z]>
The sub-pages of partial names within credits:, like Credits: A thru C, use an additional setting, -pregPagesTitleOn.
<nspages -h1 -textPages="" -exclude -exclude:start -exclude:[ambiguous_names d_g h_k l_o p_s t_z] -pregPagesTitleOn="/^[A-C].*/i">
This returns the pages that satisfy a regular expression. The pattern to be matched is enclosed between two slashes. That pattern, ^[A-C].*, matches page headings that start with “A”, “B”, or “C” and everything that follows. the i at the end makes the matching case-insensitive.
This is the simplest one. Not all of these pages in Inclusions even have Heading 1 values written on them, so the unvarnished page names are displayed instead.
<nspages -textPages="" -exclude>
The use in the "Other series" section on the main works: page differs in many ways. Most obviously, it has a tree, or nested list, layout.
<nspages -subns -noPages -tree -r -h1 -sortID -idAndTitle -exclude:[: core: other: magazines:] -textNS="">
Here is what the differing settings do.
-subns | Display namespaces, linking to their start pages. |
-noPages | Do not display pages that aren't namespace pages as above. |
-tree | Display listing in the tree style. |
-exclude:[…] | This time, entries are followed by a colon, indicating namespaces. The colon by itself excludes namespaces without start pages. |
-textNX | Suppress namespaces title by setting it to a blank string. |
The instance on Works by creation date introduces yet more options, shown and explained below.
<nspages -title -r -exclude -exclude:start -exclude:publishers: -sortByCreationDate -simpleLineBreak -hideNoPages -textPages="" -hideNoSubns>
-title | An alias of -h1. |
-sortByCreationDate | Sort the list by the date on which the page was created. |
-simpleLineBreak | Display each listing item on its own line without any list structure. |
-hideNoPages | Hide a header and message if there are no pages. |
-hideNoSubns | Hide a header and message if there are no sub-namespaces present. |
Like a Khuzan bridge in Kaldor from the Codominium, remnants of this plugin's former glory persist in the wiki today. It conditioned the wiki's development and the use of namespaces in its organization. Indeed, with the Tags plugin in use now, one could argue that that organization could be flattened and so simplified.
This has been resisted, however. Mostly, this is due to inertia and the knowledge that, once done, it would be difficult to undo should regrets ensue. Also, some hierarchy is needed to differentiate harn:kaldor:, information on the kingdom, and works:harn:kaldor:kaldor, the kingdom module itself. Besides, namespaces are useful and used within the Tag plugin as well.
It used to be worse, you know. works:fanon: used to be a namespace, and all fanon works had to be in there, branching identically to all the other ramifications of works:. Count your blessings.