Separating user defined fields from, well, all the others

#1

Hi everyone,

It’s my first time posting here though I’ve been a Tiddlywiki admirer and user for a number of years now. So let me explain my question. (If you want to know more about why the question arises see the explanation at the bottom of this post.)

To quote myself, “I’m building a Tiddlywiki to help me run a wargames campaign”. In doing so, I’ve added components to the standard tiddlywiki component set. (Though I haven’t actually modifed anything from among the standard set of Tiddler components yet).

Apart from tags, the largest set of bespoke components that I’ve added is the set of user defined fields. The number is probably trivial by expert tweaker standards but I’m now up to at least 14 user defined (UD) fields. Inevitably that’s making it hard to keep sight of the big picture, which is inconvenient and a source of error. So I thought to create a list of all the user defined fields using the fields operator. Which is where I ran into problems. Here’s the story.

First I tried using the [fields[]] Operator on its own, which yields 38 results in the Advanced Search tool. That’s clearly well in excess of the number of UD fields, even if I’ve forgotten a couple, and it’s clear from examining the list that most of them are from the standard, tiddlywiki component set.

That’s OK, it’s a journey. So I thought that if I added !is[system] to the filter run, that might do it. Like this: [!is[system]fields[]]. Well, it certainly improves things as the number of field names in the output is down to 26. So we’re only 12 over. There are no dupicates, by the way, so deduplication is clearly working.

So next I thought to check how many fields there are in the the standard, tiddlywiki component set and whether I could find any way of grouping them into categories that would be amenable to use in a filter.

Examining [[TiddlerFields|https://tiddlywiki.com/#TiddlerFields]] gave me the field names, their categories and the numbers in each category, that I mentioned in the previous section, but though the names and the numbers were helpful I couldn’t find any formal categorisation for any of the three groups nor the set as a whole that might suit my purpose.

The number of standard fields is 10, Other fields used by the core number 21, the TiddlyWebAdaptor has 3. That adds up to 24, which, together with my expecatation of 14 UD fields, gets us to the magic number, 38. It’s interesting that the number 12 (see previous paragraph) is not readily derived from that set.

If you are still with me and I won’t blame you if you aren’t, my next step was to try using the fields operator again but now adding the suffix exclude and populating its parameter with a list of the standard fields.

To save my self a lot of re-typing (well, not really) during the trials, I copied the tables of fields from [[TiddlerFields|https://tiddlywiki.com/#TiddlerFields]] into a text editor and turned them into: (a) a comma separated list without spaces or line breaks; and (b) a single space separated list without commas or line breaks. I then put both lists into a new tiddler called standard-fields, with one of the lists commented out.

Finally, I used the fields operator again with the suffix exclude and with it’s parameter field populated with a transclusion link to the native-fields tiddler, like this: [!is[system]fields:exclude[{standard-fields}]]. That still gave me 26 matches. Sigh!

I’m out of ideas now, for the moment, so if anyone can help, I’d be really grateful for your input.

Thanks for staying with me or even for starting.

Regards, Chris

PS So why am I posing this question?

The simple answer is that I’m building a Tiddlywiki to help me run a wargames campaign for my regular gaming group. I’m building it on the hoof, from an earlier version, and I’m frequently finding that I need to remind myself about what I’ve built into or on top of the standard tiddlywiki component set. As you’ve read, that’s where the problem arises.

Of course, I also find that I need then to change something across a batch of tiddlers. Now that, which should probably be the hardest, isn’tfunnily enough. That’s thanks to tools like the “Rename Tag” plug-in from Albertononi and the Tiddler Commander from Mohammed (for both of which I’m very grateful).

Btw, I think this topic is closely related to this one: [tw5] Tag manager like interface for user fields, from a couple of years back but which doesn’t have an answer.

OS: Linux; Distro: Puppy Linux, variant: FossaPup_64_9.6; Browser: Firefox (always current); TW version: 5.3.6.

#2

This filter syntax is not correct. When using a transclusion to specify a filter parameter, omit the square brackets, like this:

[!is[system]fields:exclude{standard-fields}]

As a general reminder for specifying filter parameter values… the type of brackets indicates how to process the specified parameter:

  • Use square brackets to enclose literal text
  • Use curly brackets to enclose transcluded tiddler field references
  • Use angle brackets to enclose variable references

Also note that the parameter transclusion will not ignore any “commented out” content from the transcluded tiddler, so you will need to remove the “comma separated” list, which is not needed.

enjoy,
-e

1 Like
#3

Hello Eric, thank you very much for such a prompt reply and especially for solving the problem. I’m very grateful. And that does indeed now work! :smiley:

So, in case it’s helpful to anybody else, here are the filter constructions that I know work:

[!is[system]fields:exclude{standard-fields-space-separated}] in which the tiddler standard-fields-space-separated contains a space separated list of the standard (ie non-user defined) fields (see below); and

[!is[system]fields[]]-title -text -modified -modifier -created -creator -tags -type -list -caption -class -code-body -color -description -draft.of -draft.title -footer -hide-body -icon -library -list-after -list-before -name -plugin-priority -plugin-type -stability -source -subtitle -throttle.refresh -toc-link -_canonical_uri -bag -revision -_is_skinny where the standard fields are simply appended to the filter run as a space separated list of fields, each prefixed by a hyphen.

Here are the two lists, in case anybody wants to copy and paste my possible errors. But anyone using it should note that it’s a dead list, which is likely to become incorrect in time.

"standard-fields-space-separated"

title text modified modifier created creator tags type list caption class code-body color description draft.of draft.title footer hide-body icon library list-after list-before name plugin-priority plugin-type stability source subtitle throttle.refresh toc-link _canonical_uri bag revision _is_skinny

"standard-fields-space-separated-hyphen-prefixed"

-title -text -modified -modifier -created -creator -tags -type -list -caption -class -code-body -color -description -draft.of -draft.title -footer -hide-body -icon -library -list-after -list-before -name -plugin-priority -plugin-type -stability -source -subtitle -throttle.refresh -toc-link -_canonical_uri -bag -revision -_is_skinny

#4

By the way, if anyone knows of a way to bring in the standard fields as an evergreen, space separated list please do chip in. That would be the ideal solution. Regards, Chris

#5

Wouldn’t it be easier to just put a prefix in front of all of your user-defined fields? like ud-name, ud-address, ud-age, etc so that you just have to filter for fields with ud- prefix?

#6

The historic convention (esp email) to signify user-defined fields is the X- prefix, but from memory that’s been deprecated and these days anything goes for maximum flexibility.

If a prefix suits needs, then I think X- would be the best way to ensure it’s understood as non-standard. otoh, there may be genuine reasons to avoid that?

1 Like
#7

Hi Caspar,

Thanks for chipping in. Yes, you’re right it probably would have been. And might still be. Though, as the Irish side of my family might say, it’s now more a case of “sure, if you’re going there you don’t want to be starting from here”. The big problem is that I didn’t make a reliable record of the UD fields that I created. Doh! I do have an excuse, though it’s pretty feeble. I just presumed that all the default fields in TW would be identifiable as such, so that they would be immediately distiguishable from UD fields. Ah well, you live and learn.

But, as it happens, I’m back to the drawing board anyway because, when I checked the output from both of the filter runs that I thought were working correctly, I find that at least two terms that I was expecting are still not showing up and I can’t, for the life of me, spot what’s driving their omission.

Regards,

Chris

#8

Hi Nemo,

As I wrote a moment ago, in my reply to Caspar, I wasn’t expecting to need to. Naive as that might seem now. I’d also prefer not to, though only for grammatical reasons, in that I sometimes use the field name as an input to a piece of text that’s constructed in part from the field values. But there’s no functional reason that I couldn’t do that, so thanks for the suggestion.

Regards,

Chris

#9

There are at least three reasons a person might not want to do name all their fields with a user-specific prefix:

(1) When dynamic tables use field name as column header, these headers work out-of-box very nicely with compact readable field names.

(2) Sometimes we want a field names that can correspond to a straightforward tiddler name (some data structures benefit from this pattern)

(3) If one is regularly importing JSON or other structured data from external sources (with keys/field names not under our control), retaining routine workflows and compatibility can weigh in favor of retaining most field names as they appear in the external data.

Of course, one could write workarounds to add and subtract the custom prefix as needed, but … Tiddlywiki’s flexibility of field names is a beautiful and elegant thing!

For completeness: Note that we still have the grey area of field names that play a role in the wiki because they’re defined in some plugin or external data-set. They won’t be part of a standard list of TW’s out-of-box set of fields, but they also won’t be user-defined in the usual sense.

3 Likes
#10

Hi Springer, thanks for that. Every additional insight helps as far as I’m concerned. Regards, Chris

#11

So, in helpful, interesting and irritating equal measures, I’ve just discovered that the Control Panel displays “the full set of TiddlerFields in use in this wiki (including system tiddlers but excluding shadow tiddlers)” at Control Panel>Info>Advanced>Tiddler Fields! Doh! :roll_eyes:

In addition I’ve just noticed that the " Add a new field: field, which appears at the bottom of every tiddler, displays that same list of all the fields SPLIT INTO User fields followed by System fields! Nnnnngh! Double doh! :roll_eyes: :roll_eyes:

So at least I can now count them and copy them, even if I can’t generate the list myself. YET.

There are 16 supposedly user defined fields in the wiki now, created by me, plus the “list” field, which isn’t user defined as such but which I presume is in the list because it’s content is intended to be user populated.

Now I’m wondering how the tiddler knows which fields are user fields and which are system fields?

I thought the answer was going to be simple because the system fields all seem to have descriptions, whereas the user fields don’t. But that doesn’t hold true for the system field commit:, which doesn’t have any description. So that’s not how it does it.

Looking at the list in the Control Panel, I’ve now noticed that the user defined field that my filters keep missing, which is named source duplicates a system field that has the same name, vis: source: The source URL associated with a tiddler. So given that my filters both start with !is[system], that’s not very surprising that it isn’t listed by my filter. Sigh. Triple doh! :roll_eyes: :roll_eyes: :roll_eyes:

So it looks like I’ve got to the bottom of my first problem, vis why are my filters not generating a complete list of user defined fields. But now I need to:

(a) go back and do a bulk rename all the occurrences of my supposedly user defined field source, without renaming any of the occurrences of its system twin.

(b) work out how the drop down list that the tiddler generates for the the " Add a new field: field, knows how to split the user fields from the system fields?

And by the way, I’ve just noticed that whatever routine generates the drop down list construes the field named “source” as a user field, not a system field, whereas the list in the table in the Control Panel does the opposite.

Right, time for bed said Zebedee, it’s late. Busy tomorrow so back to this on Wednesday. In the meantime any wise thoughts, insights or humorous but supportive wisecracks are all welcome.

Regards, Chris

#12

I know that I just said it’s late but I wanted to get a sense of what’s going to be involved in replacing my user defined field source with something that doesn’t duplicate a system field. And lo and behold, [!is[system]has:field[source]] tells me that I have 226 matches. It looks like it’s time that I plugged in Tiddler Commander or an equivalent, otherwise this is going to be like mucking out the Augean stables!

1 Like
#13

And tracing that through $:/core/ui/ControlPanel/TiddlerFields to $:/snippets/allfields also gives us a way to see all the field names known to the core. I’ve been looking for this.

[all[shadows]prefix[$:/language/Docs/Fields/]removeprefix[$:/language/Docs/Fields/]]

We can simplify that to

[all[shadows]removeprefix[$:/language/Docs/Fields/]]

although I personally have never been thrilled by that behavior of removeprefix.

<table>
<tr><th>Name</th><th>Description</th></tr>
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
<tr><td><$text text={{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}} /></td><td><$text text={{{ [<currentTiddler>get[text]] }}} /></td></tr>
</$list>
</table>

yields

Name Description
_canonical_uri The full URI of an external image, audio, or html file
_is_skinny If present, indicates that the tiddler text field must be loaded from the server
author Name of the author of a plugin
bag The name of the bag from which a tiddler came
caption The text to be displayed on a tab or button
class The CSS class applied to a tiddler when rendering it - see [[Custom styles by user-class]]. Also used for [[Modals]]
code-body The view template will display the tiddler as code if set to ‘‘yes’’
color The CSS color value associated with a tiddler
component The name of the component responsible for an [[alert tiddler
core-version For a plugin, indicates what version of TiddlyWiki with which it is compatible
created The date a tiddler was created
creator The name of the person who created a tiddler
current-tiddler Used to cache the top tiddler in a [[history list
dependents For a plugin, lists the dependent plugin titles
description The descriptive text for a plugin, or a modal dialogue
draft.of For draft tiddlers, contains the title of the tiddler of which this is a draft
draft.title For draft tiddlers, contains the proposed new title of the tiddler
footer The footer text for a modal
hide-body The view template will hide bodies of tiddlers if set to ‘‘yes’’
icon The title of the tiddler containing the icon associated with a tiddler
library Indicates that a tiddler should be saved as a JavaScript library if set to ‘‘yes’’
list An ordered list of tiddler titles associated with a tiddler
list-after If set, the title of the tiddler after which this tiddler should be added to the ordered list of tiddler titles, or at the end of the list if this field is present but empty
list-before If set, the title of a tiddler before which this tiddler should be added to the ordered list of tiddler titles, or at the start of the list if this field is present but empty
modified The date and time at which a tiddler was last modified
modifier The tiddler title associated with the person who last modified a tiddler
module-type For javascript tiddlers, specifies what kind of module it is
name The human readable name associated with a plugin tiddler
parent-plugin For a plugin, specifies which plugin of which it is a sub-plugin
plugin-priority A numerical value indicating the priority of a plugin tiddler
plugin-type The type of plugin in a plugin tiddler
released Date of a TiddlyWiki release
revision The revision of the tiddler held at the server
source The source URL associated with a tiddler
stability The development status of a plugin: deprecated, experimental, stable, or legacy
subtitle The subtitle text for a modal
tags A list of tags associated with a tiddler
text The body text of a tiddler
throttle.refresh If present, throttles refreshes of this tiddler
title The unique name of a tiddler
toc-link Suppresses the tiddler’s link in a Table of Contents tree if set to ‘‘no’’
type The content type of a tiddler
version Version information for a plugin

Does anyone see any reason not to use that as the (dynamic) definitive list of fields used by the core? Are there known fields which do have have this lingo mechanism applied?

If this is correct, then we could write a custom function,

\function custom.fields() [fields[]] -[all[shadows]removeprefix[$:/language/Docs/Fields/]]

to be used like

<<list-links filter:"[<currentTiddler>custom.fields[]]">>

to get a list of all the non-core fields in the current tiddler.

This is extremely useful to me. Thank you @ChrisH!

CoreFields.json (615 Bytes)

2 Likes
#14

Commander is wonderful. But it’s also worth noting that it’s relatively easy to do these bulk changes on your own. Here is a button to rename "source" to "origin" across all non-system tiddlers:

<$button>Rename 'source' to 'origin'
  <$list filter=[!is[system]has:field[source]]>
    <$action-setfield origin={{!!source}} $timestamp="no" />      
    <$action-deletefield source $timestamp="no" />
  </$list>
</$button>

Note: The above has been edited to add the $timestamp attribute, as suggested by @Greyed. This avoids changing the modified date and therefore moving these to the top of the Recent tab.


Rename Source.json (411 Bytes)

#15

Hi Scott,

I’m really glad that you found my post helpful. Thanks for letting me know. I’m also grateful to be reading your reply over breakfast with a coffee to hand because there’s a lot of learning in there for me to unpack. I’m a complete beginner when it comes to working under the hood of Tiddlywiki, or even polishing the chrome, to push the metaphor to the limit. Though I’ve been using TW for a good few years now.

The remove prefix operator is a particularly interesting discovery for starters. And the whole block of code under <table>, that creates the tabulated list of fields and their descriptions. I’ve been wanting to find out how to do that for a while. I presume it’s a macro.

I haven’t gone into those parts of the TW jungle yet, I’m just hovering at the edge of the clearing, listening to the noises. Looks like it’s time to put on my bush hat and head in. :cowboy_hat_face:

Regards, Chris

#16

Whoah! That’s above and beyond! And great learning. Thank you Scott, that’s very good of you. Best regards, Chris

#17

I assume you mean how removeprefix[...] does TWO actions:

  • filter out items that don’t have the specified prefix
  • remove the specified prefix from the items that are left

Although it is sometimes convenient to do both actions (as in your previously posted response), there are also times when you just want to remove the prefix while retaining all items, even if they don’t have that prefix. For this behavior, you should use trim:prefix[...] instead.

-e

2 Likes
#18

Yes, exactly. I always prefer the simplicity of tools that do one thing, allowing me to combine them as I choose.

Oh, yes, thank you. I use trim often, but only as I would in JS, to remove leading/trailing whitespace. I guess I never looked at the docs to realize that it had other behavior as well. Very useful; thank you.

#19

Yes, Your Honor, the defendent was found exceeding the posted limit of one extended metaphor per message… :slight_smile:

There are a lot of operators. It takes a long time to learn them all, or at least longer than I’ve been able to spend in the last few years.

And as seen in the conversation here, sometimes individual operators do multiple things, either by default, as in removeprefix or via configuration, as in trim.

There are various tools worth investigation. I assume that if you’ve been doing this a while, you’re at least passingly familiar with WikiText, but he others may be new to you.

It’s a combination of HTML markup and a ListWidget. If you’re familiar with HTML from another context, it works pretty well the same inside TW tiddlers. It’s difficult (at least for me) to get WikiText Tables to work with lists, so I usually end up with HTML for them.

How I work

Typically, I would start with a <<list-links>> macro to make sure I have the filter I want to use correct. Here I already tested the filter in the Advanced Search > Filter tab, but I still rechecked it here. So my first step would be:

<<list-links filter:"[all[shadows]prefix[$:/language/Docs/Fields/]]" >>

That displays a bulleted list of tiddler titles, and looks correct, so I mechanically change that to a <$list> widget like this:

<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
  <$link/><br/>
</$list>

Note that we now have opening and closing tags for the <$list> widget, and we’ve moved from the macro shortcut syntax of <<name ...params >> to the more HTML-like <name ...attributes> ...content </name>, where name uses the tiddlywiki convention of starting with $, so <$link ...>...</$link>. Also note the minor annoying need to switch from filter: to filter= as we switch from the macro shortcut syntax to a list widget. (This might be going away sometime soon.) Finally, we have some content that will be created for every value our filter creates. Here I use another placeholder, just to make sure my list widget is acting correctly. I include <$link />, which will create a link to the current title, followed by <br/> to add a line break between them.

When I’ve confirmed that the above is working correctly, I replace the content with the markup for my table row, and wrap the whole thing in <table> tags and add a header row. (I often skip this step, but it can help me avoid making too many changes at once.):

<table>
  <tr><th>Name</th><th>Description</th></tr>
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
  <tr>
    <td>name will go here</td>
    <td>description will go here</td>
  </tr>
</$list>
</table>

I fill in with the actual content I want for my table cells, generally one at a time, saving and confirming after each change. First I want to start with the current tiddler and remove the prefix to leave just the name:

<td>{{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}}</td>

for name is almost fine, but I don’t want it to be a link, so I wrap it in a text widget

<td><$text text={{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}} /></td>

That works fine, and now I want the description:

<td><$text text={{{ [<currentTiddler>get[text]] }}} /></td>

Et Voila!, we have our table:

<table>
  <tr><th>Name</th><th>Description</th></tr>
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
  <tr>
    <td><$text text={{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}} /></td>
    <td><$text text={{{ [<currentTiddler>get[text]] }}} /></td>
  </tr>
</$list>
</table>

This is my usual process, and most of it is mechanical and quick. Usually finding the exact filter expressions for the list – and sometimes for extracting the text cells – are the only time-consuming parts. This one took me maybe five minutes to create… and a lot longer to write up here.

Note that that bare-bones list made with <<list-links ...>> may last a good while. It’s perfect temporary filler for something I want to come back to later but don’t want to distract me now.

#20

If you haven’t figured this out by now, then good news: this actually isn’t nearly as hard as you think it is! In fact, I figured out (b) in the course of trying to update Scott’s filter a couple posts ago by just poking around the core’s tiddlers a little.

  • Scott’s language-based filter in post #13 is fantastic to show all of the non-system fields, but it has a small flaw for your use case: it won’t include fields which are normally system fields that a user has added to their own tiddlers, like you said you’ve done with the source field.

Here’s how you can do (b):

Because we’re looking for how the core does the “field” dropdown in a tiddler’s “edit” mode, I did an Advanced Search for field edit, and clicked over to the Shadows tab where most of the core tiddlers will be. In that list is $:/config/EditMode/fieldname-filter – open it, and pop up its Info pane (in the More dropdown) and look at the Fields tab. (Or you can just edit the tiddler to view them.)

See how there’s two filters there, one in a field named first-search-filter and one in second-search-filter? Those are the two filters that are used to generate the two halves of the add-a-field’s dropdown menu. The first- one shows just the user fields, and the second- one shows just the system fields.

  • You can verify what each filter does by copying it into a $list in a new tiddler and seeing what it returns.

By default, the first-search-filter field’s contents are:

[!is[shadow]!is[system]fields[]search:title<userInput>sort[]] -created -creator -draft.of -draft.title -modified -modifier -tags -text -title -type
  • By the way, this also answers your question of “why is the system source field listed in the field dropdown’s user section now?” When you add a field which is normally a system field to your own tiddlers, it becomes considered a user field by the above filter – because it now has a non-shadow, non-system tiddler which includes that field, it no longer gets filtered out here!

We don’t actually need the part of the first filter run that says search:title<userInput>, because that’s what “trims down” the list of fields as you type into the add-a-field text box. So you could simply copy the above filter, remove that bit, and ta-da! you’ve got a nice, working list of user-created fields.

But! We can make it a little tidier by simply transcluding that field’s filter directly into our new filter:

[subfilter{$:/config/EditMode/fieldname-filter!!first-search-filter}]

Note the curly braces used for transclusion there. We also need to pass it to the $list as a subfilter for it to work.

  • Note that this method will keep the search operation, but I don’t think it should be too much of a performance hit because you probably won’t have a “userInput” variable defined in this tiddler anyways.

Regarding (a):

Scott’s provided code in post #14 is your best bet! I’d just like to add a little tip to it: if you need/want to keep the current last-modified timestamps on your edited tiddlers, both the $action-setfield and $action-deletefield widgets he uses in his code support the $timestamp="no" attribute (in TW version 5.3.4 or higher.)

…For fun (shh, I was on a roll), if you have more fields than just source to change, why not make a single button press change ALL of them at once? :smiley: Replace the “FIRST-FIELDNAME-OLD” and “-NEW” in the code with the actual first field’s old and new names, and so on for additional field names.

WARNING! POTENTIALLY DANGEROUS CODE – make a backup and double-check the output of the filters first by removing the $button widget plus the “fieldrenamingaction” calls, and replacing the latter with something like this to verify the components being used:

''Tiddler:''  <$link to=<<tidtochange>> /> ¦ ''Old field:'' <<fieldtochange>> ¦ ''New field:'' <<condition>> ¦ ''Contents:'' <$transclude $tiddler=<<tidtochange>> $field=<<fieldtochange>> />

(Also, I won’t lie: the below code is super clunky. If someone suggests an improvement to it or finds a typo I’ve made, listen to them instead! :sweat_smile:)

\procedure fieldrenamingactions()
<$action-setfield $tiddler=<<tidtochange>> $field=<<condition>> $value={{{ [<tidtochange>get<fieldtochange>] }}} />
<$action-deletefield $tiddler=<<tidtochange>> $field=<<fieldtochange>> />
\end

<$button>
Rename multiple fields

<$list filter="[subfilter{$:/config/EditMode/fieldname-filter!!first-search-filter}]" variable="fieldtochange">
<$list filter="[!is[system]!is[shadow]has:field<fieldtochange>]" variable="tidtochange">

<%if [<fieldtochange>match[FIRST-FIELDNAME-OLD]then[FIRST-FIELDNAME-NEW]] %>

<<fieldrenamingactions>>

<%elseif [<fieldtochange>match[SECOND-FIELDNAME-OLD]then[SECOND-FIELDNAME-NEW]] %>

<<fieldrenamingactions>>

<%elseif [...] %>

	(continue as before for each new field, to define the old field names and their new names)

<%endif%>
</$list>
</$list>
</$button>
  • The condition variable used in the procedure’s actions is automatically set by each conditional %if statement to be the output of its own filter, so in this case it will be each new fieldname you specified for that section of the %if.

To only change some of the user-fields, you can add %if / %elseif sections for only the old tid names you want to include; everything you don’t include should be ignored. Or, you can replace the initial $list’s filter that pulls ALL user-fields with [[a specific list]] [[of]] [[fieldnames]] +[enlist-input[]] . The former is less initial work, but the latter might be speedier if previewing the field changes makes your wiki choke or get laggy since it’s working with fewer starting tiddlers.

1 Like