Welcome to PathfinderWiki! We hope you will contribute as much as you are able and that you find the community welcoming and helpful.

Current Issues

Form edits on book Facts pages can remove all authors

I moved the blurb from Treasure Vault to the fields on Facts:Treasure Vault using Form:Book and the resulting edit silently removed the Primary Authors and Authors fields. (diff)

I restored them from the diff using the source editor. To confirm this was reproducible, I moved the quote blurb header from the article to the Facts page using the form editor and clicked "Show changes" to confirm that the authors would not be removed. The diff view confirmed that the authors would not be removed. Upon saving the Facts page from the form editor, the authors were again silently removed despite the change preview indicating otherwise. (diff) -Oznogon (talk) 22:36, 14 January 2025 (UTC)

That is really scary. I am not sure what is happening here. I can not imagine how this could be a fault on our end. Must be a bug in the form extension. After the next update I will check again if this still happens and create a bug report there. Virenerus (talk) 21:20, 19 January 2025 (UTC)

Old issues

Subcategory content counts are 2x expectations

On category pages, the counts of pages and subcategories listed within subcategories are twice what's expected.

For example, on Category:Zyphus, the subcategory Category:Zyphus/Followers counts "(6 P)", indciating that it contains six articles. However, the subcategory contains 3 articles. -Oznogon (talk) 23:09, 16 January 2025 (UTC)

This is an artifact of our move to a new server and should solve itself with time. The counts are corrected after a purge. Virenerus (talk) 21:20, 19 January 2025 (UTC)

Bot conversion of blog citations inappropriately conflates posts and comments

Noticed that {{Cite canon change/Bleakbridge}} and File:Curtain Call Player's Guide.png both now use the same web citation template, Facts:Paizo_blog/v5748dyo6v5gb, which appeared in Category:Pages with errors as having combined the former citing a James Jacobs comment and the latter citing the blog post itself. (revision 543506).

The distinction is significant, but by stripping the comment's anchor from the URL and combining both citations into a single template, the automatic conversion has removed the ability to distinguish between the two and cite Jacobs's comment correctly or precisely. It's unclear how this can be reconciled, except by reverting the blog conversion of {{Cite web}} on {{Cite canon change/Bleakbridge}} or avoiding using a citation template at all in that situation. -Oznogon (talk) 23:48, 11 December 2024 (UTC)

Other affected citations:

-Oznogon (talk) 23:52, 11 December 2024 (UTC)

Damn, I was not aware that only an anchor is used to refer to comments on blog posts. That is certainly a big issue. I will go through all the changes that replaced links with an anchor tag and find a solution for this. Probably by writing them as {{Cite/Paizo blog/v5748951foev2|anchor=9}}? Is the list given by you only a selection of cases or exhaustive? Virenerus (talk) 00:59, 12 December 2024 (UTC)

I just finished going through all of the new blog citation templates that were in Category:Pages with errors, and the above list is all of the affected templates I encountered in that category. I don't know if that's a fully comprehensive list. -Oznogon (talk) 01:03, 12 December 2024 (UTC)

I went through all changes made by the replacement that changed a # and reverted all that were anchors. The citation template can't be used to refer to comments as probably the author is also different. Virenerus (talk) 02:26, 12 December 2024

Thanks for handling these exceptional cases. This effort is a great help, and fixing the other conflicts often led to corrections for several citations that had other issues. -Oznogon (talk) 19:57, 12 December 2024 (UTC)

Template:Cite/Paizo_blog/v5748dyo5lccl seems broken. It is a template page but contains a facts template. Virenerus (talk) 01:24, 12 December 2024 (UTC)

Thanks, I've moved it to Facts:Paizo blog/v5748dyo5lccl. -Oznogon (talk) 01:28, 12 December 2024 (UTC)

{{Cite web}} with multiple authors generates errors

Invoking {{Cite web}} with more than one wikitext link in the authors field causes a Semantic MediaWiki warning icon to appear on the rendered output. The icon's tooltip:

Property "Web author" (as page type) with input value "First Author]] and [[Second Author" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

For example:

{{Cite web |author=[[First Author]] and [[Second Author]]}}

First Author and Second Author. [{{{url}}} {{{title}}}].

Multiple authors are frequently cited for blog posts as used in {{File}} for images. For an example, see File:Welcome to the Convocation.png.

-Oznogon (talk) 19:04, 5 December 2024 (UTC)

This was a temporary artefact of the cite web changes within the semantic data initiative Virenerus (talk) 00:52, 12 December 2024 (UTC)

Semantic infobox series category issues on PFS 1E scenarios

PFS 1E scenarios had series entries like "Season 1 scenarios" that linked to Category:Season 1 scenarios, but I assume an infobox template was autocategorizing them into Category:Season 1 scenarios scenarios instead. In an attempt to fix this, I changed the "Season 1 scenarios" values on the Facts pages to "Season 1", etc., expecting them to recategorize either to Category:Season 1 scenarios, etc., or for those with redirects to named seasons, to categorize them using the season name like Category:Year of the Stolen Storm scenarios.

But now the infobox isn't autocategorizing them by season at all, and I'm not sure where that logic is anymore. Any ideas? I can revert the facts changes if necessary. -Oznogon (talk) 17:20, 12 September 2024 (UTC)

It would be nice if you could revert the facts changes. Right now the autocategorization is a bit in limbo, as I am currently overhauling some backend things, including the autocategorization of infoboxes. I hope to be done with it this week. I put this issue on my todo list for that. If it is not fixed by monday lets get back to this issue together. Virenerus (talk) 15:23, 13 September 2024 (UTC)

Iconic infobox replacements broke iconic navboxes

Changes by User:Bot Manual Bulk Operations on 18 October to replace {{Iconic}} with {{Person}}, such as revision 533936 on Sajan Gadadvara, also replaced {{Iconics navbox}} template invocations on iconics' articles.

The Iconic link in the infobox is also unreadable because the infobox is blue, resulting in nearly zero-contrast text on a same-colored background. -Oznogon (talk) 00:44, 17 November 2024 (UTC)

Thanks for noticing. I really broke that. Fixed the navboxes. I also changed the style to make links in the infoboxes more readable. Gotta check how it looks after the new style is live.

Sources in {{Recurring}} lists are repeating and linking to Facts

Some works are repeating inside the generated lists of works for recurring characters, concepts, and locations on product pages. For an example, see Rise of the Goblin Guild. Several works are listed twice in those lists, and the second links for those works point to their Facts namespace pages. -Oznogon (talk) 18:59, 5 December 2024 (UTC)

Fixed Virenerus (talk) 23:23, 5 December 2024 (UTC)

Looks good! Thanks. -Oznogon (talk) 01:49, 7 December 2024 (UTC)

Suggestions

I have three suggestions regarding potential technological improvements of the PathfinderWiki.

Create a special parameter or keyword that editors can assign to an image file to select it as a representation of the best available illustration of an image category. This parameter would alter the file's appearance in all image categories it's part of with a different frame, background color, highlight, or similar indicator. For example, given the special parameter, the Abadar.jpg file in Category:Images of Abadar could be surrounded by a red box instead of the white one it currently has. This would help to detect erroneous image categorization at a glance and is further discussed on my talk page.

Set all characters except spaces, or at least apostrophes specifically, to function the same way letters do in link highlighting. Both dogs and dog's should highlight the entire word instead of stopping at the first non-alphabetical character found and requiring a pipe to achieve the same effect—dog's.

Consolidate and automate the creation process of redirects with the creation of the pages they target. This would likely involve manually listing all desired redirects within the target page, similarly to listing the categories of an article. Except the redirect list would automatically generate every redirect page listed upon the article's creation, and renaming the target page would automatically retarget all of its redirect pages in bulk. Meanwhile, changes to the redirect list within the target page should automatically move, rename or delete the appropriate redirect pages. This is discussed in further detail on Help talk:Redirect.

The automation of redirects is a particularly challenging endeavor, but hopefully the other two suggestions are more feasible. Thanks. --Rexert (talk) 00:06, 20 March 2025 (UTC)

For context as a previous tech admin, I'm not aware of core MediaWiki options to facilitate these. If no extension provides a solution out of the box, each would likely require a bespoke solution that Virenerus or a future tech admin would have to create and maintain indefinitely.

Highlighting specific images within a category page would likely require some form of extension since adding conditional CSS classes to category lists would require attaching to MediaWiki hooks (probably in CategoryViewer). A combination of installing and configuring Extension:Highlight Links in Category, categorizing each image to be highlighted, and narrowly scoping CSS limited to the category namespace/NS 6 in a Gadget might be able to accomplish it, but only if the extension also adds CSS classes to links in category pages. The extension has also not been maintained for four years, and its last supported version of MediaWiki is one that's out of upstream support.

Either way, I'm not sure this improves the more fundamental editor-side labor issue of manually categorizing images to highlight them. (An alternative to categorization might be implementing semantic data in File namespace content and adding an attribute, but the category listings would still require an extension to hook into the list rendering to highlight them.)

Linktrail rules (word-ending links/[[word]]s) are defined in MediaWiki and controlled by localization. I don't know what specifically would be required, but linktrail rules might be modifiable by manually editing the $linkTrail rules directly in the translation. However, customizing linktrails in this manner would make updating MediaWiki more difficult, since the bespoke modifications would have to be tested against and patched into every MediaWiki update's updated translations.

An alternative might be to create and maintain an external text replacement bot that attempts to replace wikitext links, such as replacing [[(.*?)]]'([a-z]*) with [[$1|$1'$2]], potentially with additional lookarounds to avoid breaking surrounding punctuation or markup (for instance, to avoid false-positive matching a link in ''[[italics]]'' versus ''[[plural possessive links]]''' in italics.)

Automating the work around renaming an article might be the easiest of the three, and also the most valuable since moving and renaming articles and their corresponding category trees and Meta pages is labor-intensive and manual. Doing so would likely require an external automated bot and a parameterized template to trigger the bot.

The labor of listing redirect targets manually within the target articles as proposed would likely be unnecessary or redundant if the bot itself can store and track the states of redirects and their associated target articles (via the allredirects API), and vice versa (via the redirects API).

-Oznogon (talk) 02:48, 20 March 2025 (UTC)