Table Progress Tracking is a feature that allows users to keep track of their personal progress related to wiki content on tables — such as completed actions in a video game, watched TV show episodes, or read chapters of a book. It complements the existing progress tracking tool available on Interactive Maps.
How does table progress tracking help visitors to my wiki?[]
When readers consult certain tables on your wiki - for instance those listing collectibles, achievements or easter eggs - they may be working on beating a challenge, trying to reach 100% completion on a game, planning out their next steps while playing, or simply want to see how far they have come. If you add tracking to a table, you enable them to visualize and save their individual progress!
How can I use it on my wiki?[]
If you know of a table on your wiki that would benefit from progress tracking, to begin using the feature simply adapt its code by wrapping it with the following parser tag:
<table-progress-tracking table-id="1" unique-column-index="1">
{| class="wikitable sortable"
! Column 1 !! Column 2 !! Column 3
|-
| Row1-1 || Row1-2 || Row1-3
|-
| Row2-1 || Row2-2 || Row2-3
|-
| Row3-1 || Row3-2 || Row3-3
|-
| Row4-1 || Row4-2 || Row4-3
|}
</table-progress-tracking>
Tables must meet these requirements to be compatible with progress tracking:
- The table must follow standard MediaWiki syntax.
- Headers must be at the top; rows should be vertically oriented.
- No header cells are allowed in the same row as the data source.
- Only one table per tag is supported.
You can see the mentioned example below:
|
|
Column 1 | Column 2 | Column 3 |
|---|---|---|---|
|
|
Row1-1 | Row1-2 | Row1-3 |
|
|
Row2-1 | Row2-2 | Row2-3 |
|
|
Row3-1 | Row3-2 | Row3-3 |
|
|
Row4-1 | Row4-2 | Row4-3 |
You can also use the feature with templates in the same way, if they are displaying tables and if you're only using one template. A similar example would be:
<table-progress-tracking table-id="1" unique-column-index="1">
{{Table}}
</table-progress-tracking>
How does it work?[]
Table Progress Tracking feature on Terraria Wiki.
Once implemented, a new column appears on the left side of the table. This column includes a progress tracking icon in the header (or a custom label) and empty checkboxes for each row.
Users can click the checkboxes to mark/unmark table rows—effectively tracking their progress on the content described in the table. Tracked progress is saved individually for each user. This means your progress is saved to your account and persists across browsers, sessions and devices. Only you can see your progress.
The table remains sortable, including by the progress column—allowing users to group completed and pending items.
Parameters[]
The following parameters are crucial for the system to properly store and display every user's checked progress.
Table-id[]
All tables need to include at least the table-id parameter. It's a unique identifier for the table within the article and must meet these criteria:
- Maximum 64 characters
- Only printable ASCII characters
- Must be unique on the page
In the examples on this page, table-id is assigned a numerical value. You may find that a better table-id would be one that reflects the nature of the table, like "achievements" or "accessories" (lower case is standard for ids). Tables sometimes get transcluded into other pages, and if the table was assigned a numerical id, it will be problematic if a table with that id already existed on that page.
Unique-column-index[]
Users can also include the unique-column-index parameter, which indicates which column contains unique identifiers for each row. It has to meet these rules:
- Must be a number
- Values range from 1 to the total number of columns
- Column values must be unique
- Column values must have a limit of 64 characters
The feature will interpret the cell content as the ID. When trying to choose the most appropriate column to get it as the unique-column-index, you have to keep in mind it needs unique values (to not duplicate the same info in more than one row), but also that these values (cell contents) have to be short (less than 64 characters). If your table doesn't meet these requirements, you can use data-row-id and specify id names for each row, shorter than this limit.
Data-row-id[]
If you expect the column might contain duplicates or prefer more control, omit this parameter and use data-row-id instead, with a unique identifier for each row:
<table-progress-tracking table-id="1">
{| class="wikitable sortable"
! Column 1 !! Column 2 !! Column 3
|-
| data-row-id="1" | Row1-1 || Row2-2 || Row3-3
|-
| data-row-id="2" | Row1-1 || Row2-2 || Row3-3
|-
| data-row-id="3" | Row1-1 || Row2-2 || Row3-3
|-
| data-row-id="4" | Row1-1 || Row2-2 || Row3-3
|}
</table-progress-tracking>
In this case, they have to meet these requirements:
- Each row must have a unique
data-row-id(max 64 characters). - The ID can be placed in any cell; only the last one is read if duplicated in the same row.
- If both
unique-column-indexanddata-row-idare used,data-row-idtakes precedence.
If you don't specify the id for a row, the feature will interpret the cell content as the ID. In this case, if the cell contains a text with more than 64 characters, it can't be used, and you will see an error message. It's solved by adding specific data-row-ids for all the rows, or at least the ones with content larger than 64 characters.
If an editor modifies a table and changes the ID of a row, any progress previously saved by users will be lost. Using unique-column-index increases the likelihood of this happening, as its values may change more easily with table edits. In contrast, using data-row-id reduces this risk, since the IDs are explicitly defined and tend to remain more stable over time.
Additionally, switching from unique-column-index to data-row-id (or vice versa) will reset all previously saved user progress—unless the values used in both methods are exactly the same for each corresponding row.
Header-label[]
Header-label is an optional parameter that sets the header text for the progress column. For example:
<table-progress-tracking table-id="1" header-label="Collected?"> [...] </table-progress-tracking>
If omitted, a progress tracking icon is shown by default.
Exclude-row-indexes and data-tpt-excluded[]
These optional variables can be used to exclude some concrete rows from progress tracking. Sometimes, tables include extra rows that are not including data elements (such as initial or final notes, a sum or recap of all previous elements, any kind of element that would need 1 or more rows to extend explanation about it, secondary headers or titles, etc.), or this data is simply not trackable (for instance, because it contains items that you already have by default, or they are unobtainable, etc.).
To refine the use of the progress tracking feature and keep into account these contexts, the exclude-row-indexes defines which concrete table rows can be opted-out of the tracking functionality. Once you're defining them, these marked rows will not display a checkbox. In addition, no ID validation would apply to them.
You have different options to use the variable, based on the most accurate case you need it:
- If you want to exclude specific rows, you can just use the parameter with the number of the body row you want to. You can do it for more than one, separating the numbers by semicolons. For instance,
exclude-row-indexes="2;4;7"would exclude the second, fourth and seventh body rows. - If all your data is following a pattern of 2 paired rows to display data about the same element, and you want to always exclude every even row, you can just use
exclude-row-indexes="%2". - If you want to exclude all the following rows after a concrete one, you can add
gt. For instance, usingexclude-row-indexes="gt5"would exclude all rows after the fifth body row. - Alternatively, using
ltwould exclude all the initial body rows before the one you mention.exclude-row-indexes="lt5"would exclude all the initial body rows before the fifth one.
Always take into consideration that row indexes are always counted starting from the first body row (the first row that contains at least one <td> cell), so you don't have to count the first row used as header.
A real example of a table with the progress tracking excluded from the second and fourth body rows is the following one:
<table-progress-tracking table-id="exclusion-example" exclude-row-indexes="2;4" unique-column-index="1">
{| class="wikitable"
|-
! Column 1 !! Column 2 !! Column 3
|-
| A || Row1-2 || Row1-3
|-
| A || Row2-2 || Row2-3
|-
| B || Row3-2 || Row3-3
|-
| B || Row4-2 || Row4-3
|}
</table-progress-tracking>
This example would be displayed in this way:
|
|
Column 1 | Column 2 | Column 3 |
|---|---|---|---|
|
|
A | Row1-2 | Row1-3 |
| A | Row2-2 | Row2-3 | |
|
|
B | Row3-2 | Row3-3 |
| B | Row4-2 | Row4-3 |
If you don’t want to identify the index of your selected row in the header, alternatively you can also add the data-tpt-excluded variable directly in the row, as you usually do with data-row-id.
This example:
<table-progress-tracking table-id="exclusion-example-2" unique-column-index="1">
{| class="wikitable"
|-
! Column 1 !! Column 2 !! Column 3
|-
| A || Row1-2 || Row1-3
|-
| data-tpt-excluded | A || Row2-2 || Row2-3
|-
| data-tpt-excluded | B || Row3-2 || Row3-3
|-
| B || Row4-2 || Row4-3
|}
</table-progress-tracking>
Is excluding the second and third body rows without using the initial parser tag to specify them:
|
|
Column 1 | Column 2 | Column 3 |
|---|---|---|---|
|
|
A | Row1-2 | Row1-3 |
| A | Row2-2 | Row2-3 | |
| B | Row3-2 | Row3-3 | |
|
|
B | Row4-2 | Row4-3 |
Frequently Asked Questions (FAQ)[]
- How can I use the tool?
- The only requirement is to have and log-in a Fandom account, to save your progress data.
- I don't have an account yet. How can I use the tool?
- If you don't have an account, or you're not logged in, you will anyway see the feature in the table. Once you click on a checkbox, you'll be redirected to the Fandom Auth page to create an account - or log-in, if you already have one - and later you will return to the table and start using it.
- How is the feature included in tables?
- The feature has to be manually added on each table a person decides is relevant for progress tracking for everybody. It is not an automatic process. Users have full control over this decision. Any editor is able to edit the page and add the required code explained in this help page.
- What happens if a table includes the feature but it shouldn't have it?
- If a table is not relevant for progress tracking, you can easily undo the wrong edit the user did. You can undo the edit (as any other kind of bad edit) or simply go to the page and remove the code we use to show the feature.
- And what happens if a user removed the feature but it was useful?
- The same. You can go to the page again, edit it, and add the code again. You can check the history of the page to see which concrete code was used. Or if the edit was recent, you can undo this edit and return to the previous version.
- What if a user changes the table itself?
- If someone is changing the content of the table, including the info used for the ID, the progress is reset. However, if you're changing or adding only a few rows, the progress about them is the only thing that would be new, while the rows that remain the same between edits should retain their progress status. If you decide to return to the previous status of the table (the "same table" you had), all the saved progress for all users would return. In addition, as explained, if you're changing the content on some concrete cells, but the info used to get the identification remains the same - for instance, you use the first column as the unique identifier but you're changing info in the fourth column - you would keep the previous progress status.
- How are you saving the data about progress?
- The data about which progress you have on each table is individually saved in your account. You will only see the progress you're marking with your account on this table. This would interfere with what other users are doing with the same table. The data is permanently saved, you can close or refresh the page and the progress would remain there.
- What's the difference between
unique-column-indexanddata-row-id? - Both can be used to define the uniqueness of the table identifiers.
Unique-column-indexis usually more used because it's easier and quicker to implement. Once you find a column with unique data, it can be used as reference.Data-row-idis actually a more refined option, because you can have more control on which data you are using and how unique it is. Also it reduces the risk of losing progress data if someone else is editing the table data. On the other hand, if you're implementing the feature on a long table, you would have more work to add these specifications, whileunique-column-indexonly needs a valid column. - A table is using DPL or Cargo. Is the feature compatible with them?
- Tables using the DPL or Cargo extensions are usually more complicated to be interpreted by the feature in order to get the data and be able to interact with the progress tracking tool. However, we've been working to make tables compatible with the Table Progress Tracking feature. If you find any kind of related issue, please contact us.
- I've tried to use files as the identifier but it didn't work. What can I do?
- If you're trying to use a column that only contains files as the unique identifier, it won't work. While files can contain unique images for each row, when the feature wants to get info for the identifier, it strips most of the tags and only leaves the text values of the tag. For most cases, files don't have text value and the feature simply sees this column "empty" for this purpose. Same applies for other cases like non-text wikitext objects. The best solution is simply choosing a column with basic content including text values, like the names of each row element, to ensure they can be used and each row contains unique content.
- I've properly added the code to include the feature in a table. However, it doesn't work. What's happening?
- In some cases, you're able to include the code to use the feature in a table, but the feature is not working on any of the tables in the same wiki. You will notice the tables have the new column with the checkboxes, but when you're trying to use them, you'll see a 🚫 icon, and also a new popup in the corner of the wiki with the message "An error occurred while loading the table progress data. Please try again later". If you experience this issue, it's because of a problem with the database update we implemented when we launched the feature. Unfortunately, some wikis failed when they tried to update their database. To fix the issue, you need to contact us and request a new database update.
Useful links[]
- Table Progress Tracking feature is now available for all wikis
- Table Progress Tracking: How It's Going
Further help and feedback[]
- Browse and search other help pages at Help:Contents
- Check Fandom Community Central for sources of further help and support
- Check Contacting Fandom for how to report any errors or unclear steps in this article
- Ask for help and give feedback on Table Progress Tracking in the #progress-tracking channel of the official Fandom Discord.