Recent content by Jeremy P

I doubt it was in a template. I can't reproduce it here though. Worth testing on a default style with all add-ons disabled, and if it persists you can post a new bug with reproduction steps. Note this bug specifically occurred when editing the first post in a thread (rather than using the 'Edit...

Not currently but it is forthcoming in 2.4: https://xenforo.com/community/threads/featured-content-improvements.229454/#-full-rest-api-support

The same technique described here applies: https://xenforo.com/community/threads/custom-prefixes.222693/post-1688837

.structItem.structItem--thread.is-prefix1 { background-color: yellow; }

The display conditions just control whether or not to display the widget, meaning the conditional will cause the widget to be displayed to users belonging to group 37. It has no bearing over the content of the widget. You could instead edit the widget_birthday template and replace the wrapper...

The rows have a class of .is-prefix{id} so you can use that to target them for whatever CSS you want.

You'd have to add it in your front-end template: <xf:js> XF.extendObject(XF.phrases, { my_phrase: "{{ phrase('my_phrase')|escape('js') }}", my_other_phrase: "{{ phrase('my_other_phrase')|escape('js') }}" }); </xf:js>

You could do it based on their ID: $xf.visitor.user_id === 123

There is no total in that sense as the scores and weights are relative to each other. For example, using the quoted configuration, a thread with ten reaction points and no replies will have a trending score of 200, where a thread with two replies and one reaction point will have a trending score...

This is as-designed, we don't visually distinguish banned members out of the box beyond the strikethrough displayed to staff. You may enable the option to add banned members to a user group to override their user title, if you wish.

I tested the exact steps described before triaging and received it just fine, and we’ve received no other reports of this. If you can reproduce this reliably with all add-ons disabled on the latest version, you can share the steps and I can try again.

I can't reproduce this, and we don't apply discouraged checks to the API endpoints at all. My best guess is that PHP-FPM was saturated from public requests and therefore unable to handle the API requests.

I'm not sure we can really change this as-is since it breaks backwards-compatibility. You can use eg. ?posint to allow for null values for missing data if that's preferable.

We do set nofollow on them already, so if they are displayed to guests then its kind of up to the crawler to respect that or not.

This is as-designed for our pairs styling. You could customize the field's wrapper display HTML to justified, for example, or make other adjustments via extra.less: <dl class="pairs pairs--justified pairs--customField" data-field="{$fieldId}"> <dt>{$title}</dt> <dd>{$value}</dd> </dl>