This is implemented in the next release, at least for XenForo 2.x. We may backport support for other platforms if there is enough demand.
I should note that this does not use the underlying AbstractField classes in XenForo 2. There are significant differences in the way the fields work that it became almost meaningless. You'll see as I explain the implementation.
History
Custom field values are tracked in a page's history, and are outlined in each revision's change summaries. When comparing revisions, custom fields are also diffed and highlighted accordingly. Custom field changes are also reverted by rollbacks.
Admin Page
For the most part, the new AdminCP > Content > Custom Fields is a clone of the Thread Fields page. Except you choose to apply each field to areas instead of forums. Additionally, you choose which wiki content-types the field applies to within those areas. And additionally you can choose which areas have templates that can populate the field (more on this later).
Most of the field types and match types are clones of what you know from XenForo's Thread Fields. However, if you want to translate the phrases for a field, the names are as follows:
- vw_custom_field_{fieldname}_{title|description}
- vw_custom_field_{fieldname}_choice_{choiceValue}
The date type has been changed to permit accepting times too.
The following field types have been added:
- Wiki Page
- Wiki File
For both of these, you can choose to render it as a link or to transclude/embed the target.
The following display groups are available:
- Top (between the title bar and the page content)
- Bottom (between the page content and the categories, contributors, etc)
- Infobox (makes it available to a new XF widget, which you'll need to setup separately in the Widgets AdminCP page if you use this grouping)
- Details Tab (the page now has a Details tab, containing all fields in this grouping)
- New Tab (the field renders as its own tab; you can define the URL's action parameter)
- Metadata (the field is only used as invisible page metadata. How is this useful? See below)
There is an option to make a field searchable. If this is selected, the search metadata is generated as follows:
- The fields are rendered in plaintext and prepended to the wiki page's content. For choice-fields, the choice text is used. Keywords that appear in choice-text or textarea/bbcode/textbox-related fields will trigger search results.
- Choice fields, number fields, wiki page, wiki file are available as search metadata fields (n.b. this kind of metadata supports matching only, not greater/less than comparisons). They can be used for custom search filters by other add-ons, or maybe we will expand on this in core in the future.
Template Fields
If you setup a field's config so that it is available to templates in an area, then you can template some field values, so that pages that use the template populate their own field values, if the page has that field but has left it blank. In this way, you can ignore filling a required field if you use a template that will fill it. Templated fields permit dynamically generated field values for any field type.
When editing a template, in addition to any custom fields the template itself has (for its own metadata), the fields that can be templates are presented. However, regardless of the field type, you will be filling in a text box with BB-Code. That way you can use IF, VAR, template-parameters, etc in order to generate a value.
Note that a page will only get a templated value if the field evaluates to one that validates based on the field type. Some examples:
- If the underlying field type is supposed to a date, it must evaluate to date format.
- If the field type is supposed to be a Wiki Page/File, it must evaluate to Prefix:PageTitle.
- If the field type is supposed to be a select or radio, it must evaluate to one of the values therein. The editor will show the options and their corresponding values.
- If the field type is supposed to be a multi-select or checkboxes, it must evaluate to a comma-separated list of the values therein. The editor will show the options and their corresponding values.
VAR
There is a new related option for the VAR BB-Code.
Render a page's custom field:
Code:
[var]field|myFieldName[/var]
Get the raw value for the page's custom field:
Code:
[var]field|myFieldName|raw[/var]
Render a field from a different page:
Code:
[var]field|myFieldName|Prefix:PageTitle[/var]
(add |raw to get the raw value)
Note that when saving a page, values inherited from a template are not yet available to VAR, and cannot be made available -- there would be a chicken vs egg problem. This means you should not use VAR-field to retrieve values inherited from a template for certain purposes like: generating a link, defining a Wanted Category, passing to another template. In these cases, you must set a custom field value for the page itself in order for it to be available.
October 28, 2018 1:25 PM
Distinguished Member
Originally Posted by pegasus
Please Wait