List of All Fields Used By the Core?

,
#1

The documentation has a page TiddlerFields which lists “Standard Fields” along with “Other fields used by the core.” It also shows how to find all fields on all (non-shadow) tiddlers in the Control Panel. However, it does not list all fields that some part of the core or another can use if any tiddler has them (but, because it is possible for no tiddler to have them, in which case they will not be listed in the Control Panel).

For example, looking at the list-thumbnails macro, going to the examples, and figuring out how the tiddlers tagged HelloThumbnails are getting displayed as thumbnails by the macro, one can deduce that the macro uses the image field to get the tiddler with the actual image, the link field to find the tiddler to navigate to on click. (As a side note, the list-thumbnails macro documentation itself needs explanation of how to create such a “thumbnail” tiddler that the macro can use.) However, neither of those fields are listed in the TiddlerFields list of fields used by the core (or standard fields). Additionally, in a new wiki, since no tiddlers with those fields have been created, they are not listed in the Control Panel either.

Is there a more exhaustive and/or up-to-date list of all fields used by TiddlyWiki?

#2

If you use the filter [all[shadows]fields[]] in the AdvancedSearch - Filters tab you can see, that “the core” uses 43 fields

The rest of them shown in the ControlPanel are from the tiddlywiki.com documentation content, which is very specific to the TW docs.

But you are right. This info could benefit from “some love”

IMO it would be good to raise an issue at GitHub otherwise it will be forgotten.

1 Like
#3

I am not looking for all fields that exist in tiddlers; I am looking for fields that, if provided, will be used or have some effect. For example, I have a wiki in which _canonical_uri does not exist because I haven’t added it to any tiddler. But it is certainly used by the core.

Thanks for the suggestion. I will be sure to do this once I figure out how to use GitHub.

#4

That is what the TiddlerFields page is for, as it relates to the core. On tiddlywiki.com there are macros and fields for the Documentation installed there.

Perhaps you can tell us why you want this?, because that can help us solve the bigger picture for you.

However many such macros, and plugins allow you to implement them in different ways and what fieldnames they use is up to the designer or user. Similarly how they are documented.

There are a number of search strategies starting with TiddlyWiki.com to learn about what and other fields are used.

  • One approach people take when creating new fields is to add a prefix to distinguish it from other fields.
  • I like to use generic fieldnames and they rarely have a clash. It may also be possible in many cases to reuse the same fieldname for different purposes depending on how they are made use of.
    • A simple may be a “phone” field, you may have a view template that on “contact tiddlers” presents a button to click to call, but in another tiddler type simply display it, as plain text.
#5

I wanted to make a tool for adding custom fields to tiddlers and have a tiddler containing “reserved field names” (one to which the user can add additional reserved field names, such as those used by plugins they have installed) that cannot be used by the custom field tool.

That said, upon further thought, fields used by macros that themselves aren’t used by the core (such as the <<list-thumbnails>> macro) won’t break anything if you make fields of the wrong format for such macros. They could only potentially break the user’s own use of such macros, but if they are adding those fields, then they are probably not already using such macros.

As such, it’s probably sufficient to have a list of fields that have special behavior in TiddlyWiki itself, such as tags, text, type, _canonical_uri, etc. (not just special use in certain macros that aren’t used in the core UI or anything).

For those purposes, most likely the documentation page on TiddlerFields (linked in the original post) is sufficient.

As a side note, I will open an issue at Github for that page in the documentation because it states:

Field names must be lowercase letters, digits or the characters - (dash), _ (underscore) and . (period).

Whereas, as of 5.2.0:

The major change in this release is that the format used to store tiddlers in TiddlyWiki’s HTML file has changed from an HTML DIV-based format to a new JSON-based format. The consequences of this change are far-reaching. They are thus the primary rationale for bumping the version number from v5.1.x to v5.2.0:

Firstly, the characters that can be used in field names are now unrestricted (just like tiddler titles), making it possible to use fieldnames like My^Field or ☃️. This has become possible because every other part of TiddlyWiki was already capable of dealing with unrestricted field names apart from saving as an HTML file.

#6

Keep in mind you can test if a suggested fieldname already exists and use a second suggestion (or more) if it is. However not all plugins will create a field it uses, until the right circumstances demand it.

However personal experience shows even when using the same fieldname for different purposes, it rarely has a negative effect, because each process that uses that field is somewhat independent and operates on different tiddlers any way.

When using or writing a solution that makes use of a field name, add some context such as when using the phone field on contact tiddlers do this, and another plugin may be saying if there is a phone field generate a button, we do not care if both are true they still work, that is in part because phone by definition holds phone numbers.

If you are concerned because that field may have a big effect, such as cause looping, use another name such as pluginname-phone, or macroname-phone … or contactname-phone (for contacts only), would you put a contactname-phone on a recipe ingredient?

1 Like
#7

True - it would seem pretty rare for a conflict to arise, and even if it does, the user should be able to adjust their field names if needed.

I also discovered (by looking at the edit template code) that there are a bunch of $:/config/EditTemplateFields/Visibility/<field name> shadow tiddlers to hide a bunch of the most important fields from the field editor portion of the edit template.

#8

Yes, I also told you about that in another reply recently.

#9

Yes :slightly_smiling_face: though I discovered it on my own before you told me

#10

I did just create a PR to get more info from the ControlPanel Fields table.

add a search button to the control panel tiddler fields tab #8157

323924181-bac60df2-09c2-4506-bc33-808774e0985d
323924181-bac60df2-09c2-4506-bc33-808774e0985d1569×946 39.6 KB

1 Like