Pathfinder Online Wiki
Log in

Pathfinder Online Wiki talk:PFOWikiData

From Pathfinder Online Wiki
Revision as of 19:35, 22 October 2014 by Yoda8myhead (talk | contribs)

← $1

Mass deletions

Is there a way to delete a large number of files at once without having to manually click Delete on each page? There are some leftover artifacts from prior attempts that I'd like to clean up. Nihimon (talk) 22:50, 17 October 2014 (UTC)

I can do that with my bot, but I'll need to get it set up on PFO wiki, as it currently only works on the main wiki.—Paizo Publishing, LLC.png Yoda8myhead (talk) 23:25, 17 October 2014 (UTC)
I can do it with my bot as well, but was wondering if there was an easier way. I'll handle it. Nihimon (talk) 23:26, 17 October 2014 (UTC)

I'm using my actual account since the nihimon-bot account doesn't have Delete permission. If someone could fix that, I would appreciate it. Nihimon (talk) 00:03, 18 October 2014 (UTC)

As an admin you can make other accounts admins by editing their account privileges, but I'll take care of it in this case. —Paizo Publishing, LLC.png Yoda8myhead (talk) 00:07, 18 October 2014 (UTC)

Broke things

Some things are going to be temporarily broken. I'll have them fixed tonight. Nihimon (talk) 00:10, 18 October 2014 (UTC)

Tables generated by category?

Is it possible to use Categories to put all the Feats that are categorized as Cantrips into a Table? Nihimon (talk) 14:37, 18 October 2014 (UTC)

As far as I know, it is not.—Paizo Publishing, LLC.png Yoda8myhead (talk) 20:28, 18 October 2014 (UTC)
Continuing that line of thought, I'm very curious if you have any ideas on how to organize the data in a way that we can include various bits and pieces of it in different places. For example, there will be a list of Effects for each Attack Feat, and it would be nice to display them in full in a list on that Feat's page, but it would also be nice to get a short summary of them (just the Effect name without the modifiers and conditionals) for inclusion in the tables where we list similar Feats, so that folks can see at a glance what Effects the Attack applies, and what States it capitalizes on. -- This unsigned post was made by Nihimon. Please sign all posts with ~~~~.

Nested templates is the way to go for those. We do something similar on PFwiki, in our navboxes. We have a series of templates which are just unnumbered lists of products, regions, etc. Then when we need that list, we just call the template, defining its display parameters each time the template is passed onto another page. When we need to add new items to the list, we only need to add them in one place. I know there are several tooltip extensions that we could also try out, so that a user could mouse-over a keyword and see a short description of its definition. I think getting that working should be secondary to getting the data on the site and formatted in an easily readable manner, however.—Paizo Publishing, LLC.png Yoda8myhead (talk) 19:35, 22 October 2014 (UTC)


I have been hoping to have more of a collaborative discussion about this project here. I feel very good about the process I have in place to read, parse, and normalize the data the devs share with us, but I have some questions about best practices for making that data available on the wiki in a way that ensures we can make bulk updates when that data changes. If anyone with significant wiki experience would be willing to participate, I'm confident we could move forward. My instinct is to pick a relatively simple starting point (Cantrips) and simply work through the challenges at each level. Once that is done, I am reasonably confident we could replicate that general process elsewhere with less hand-holding.

  • 1. What is the best practice for making the exact same data available in both a list and as a single element?
My initial attempts to solve this problem started with the list, and tried to create methods to extract individual items from that list. The advantages of this approach is that it would have allowed ad hoc grouping of similar items by filtered categories, so that users would have been free to create templates that filtered information from a variety of sources with confidence that their efforts would reflect up-to-date data when new data was published. The major disadvantage is that it seemed to break the wiki server. I don't have enough experience with wikis to really understand what happened, but there was a very clear correlation between my writing these data files and the wiki performance getting radically worse. Without assistance, and unable to solve these problems on my own, I abandoned this approach.
Another option that occurs to me is to have the data written only for the individual items, and have all the lists simply reference the individual data. The major disadvantage of this approach is that the groups must be defined ahead of time so that the process that writes the wiki pages can write updated group lists when the data changes; any ad hoc groupings that are created by users will be stale, and likely to include bad data (for example, if an item is removed from the game but not removed from the ad hoc list, or more likely if a new item or feat is added to the game).
The least attractive option to me is to simply copy the data into both places, but if there are compelling reasons why this is actually a reasonable way of doing it, I'm open to it.
  • 2. How can we support ad hoc groupings of similar items without creating a fragile system that will require user-intervention when new updates are available? Or, is that requirement for user-intervention a problem worth avoiding?
  • 3. Am I wrong to try to separate the data from the user contributions? This is a fundamental assumption I'm making, but it's based on my experience working with data, not on any experience working with wikis. If it's wrong, I'm open to hearing that and trying to change the way I think about this probject. -- This unsigned post was made by Nihimon. Please sign all posts with ~~~~.

I appreciate bringing the discussion here where the entire community can participate and refer to it later should anyone in the future question how early decisions were reached. I'll address each point individually below.
  1. I think we need to work backwards, first determining what information we want, how we want it displayed, and in what ways. Frex, If we want all cantrips to appear in the article Cantrip, as well as a subsection of the article Feat, and we wanted each cantrip to have its own article with a picture of a character using the feat and a bit more flavor about it than you can say in a table, we need to make sure that the data can be used in all three formats with as few data templates (for lack of a better term) as possible. That may mean that we need to have two different data templates, one for tables and one for infoboxes. It should be possible to have two different xml exports of a spreadsheet to automate the process of populating these templates, but I still need to invest a bit of time in researching and experimenting with that. In any case, we'll want to standardize them as much as possible from the onset and stick to it, which is why I think we should make a clear plan of how it will work before we do anything. Making a sample page with fake data is likely the way to go, but I don't know if we're even there yet.
  2. I don't know if we can. We can easily have our templates auto-categorize feats into categories based on any number of parameters, but that will only allow all similar feats to be accessed together through the category tree. We're always going to need to manually add new line items to tables, even if the data on those items is held elsewhere.
  3. I think all users should have the ability to make changes to the data. If there's a change that happens that someone on the wiki notices, they should be empowered to make the changes necessary to keep things up to date. Nothing discourages folks from editing more than being locked out of certain parts of the wiki. If we run into issues of vandalism, we can address them individually, either by protecting the individual pages people are vandalizing, or taking punitive action against the perpetrators. But it's in the wiki's best interest to let as many people as possible make changes to as many possible pages, including the data at the core of the proposed system. Doing so gives everyone a sense of ownership over the project and serves as a bus plan should those with permission to edit sensitive material leave the project for whatever reason.
I hope that addresses everything. I've set up the workings of a forum for general discussions like this, but there's an extension or two I need to get installed onto the server to make it work. In the meantime, we should continue the discussion here, only moving it there once it's working. —Paizo Publishing, LLC.png Yoda8myhead (talk) 19:35, 22 October 2014 (UTC)