These were reported by Tweeticoats and kanaza on Discord but I'm repeating them here for posterity:

does not work on a brand new instance creating a new performer with nothing configured

performerCreate: input: performerCreate getting SQL value for field "full": unsupported custom field value type: map[string]interface {}

• if a value has been set once, you can't go back to an empty string (it defaults to "0")
• in that case it's also no longer possible to enter dots "."

In my own testing I've found that the CSS class names for custom fields will probably need another pass as well: I created a field called "Maiden name" and it's getting the class detail-item-title custom-field-Maiden name.

One of the reasons I tested this is because I imagine that people who want custom fields might value them highly enough that they'd want to use custom CSS to change their display order, maybe even placing them above the regular fields. I'm no CSS wizard, but would the current implementation with the extra div also get in the way of that goal?

Hey, I'm testing this right now and it's looking good. I got inspired with how these fields were being added and was thinking how they could be utilised to track the historical changes of performers (and other types) according to user activity. I think I could probably make a plugin that could write certain events from logging or other detection to this table. If WP thinks this could be part of core functionality, I could work on implementing it with some assists.

Perhaps it would be worth including an additional, optional , field to the custom_fields table for categorisation? It is not necessary for the above, but would make things cleaner. I was just inspired in one direction and thought there could be other cases where an optional field here could be useful. In a future-proofing sense, especially if other object types will eventually have a similar functionality.

Here's an example of how that additional field could look like from the SQL DB and how the historical data could look from the DB :
table: performer_custom_fields
performer_id, field, [NEW! Category], value

4953, Pnalike, [User Field], Princess D*a
4953, Rating, [User Field], 8.7

4952, Birthplace, [Scraped from pedia], Massapequa
4952, Instagram Followers, [Scraped from *], 105K

table: performer_custom_fields
performer_id, field, [NEW! Category], value

4953, **** alike, [User Field], Princess D****
4953, **** Rating, [User Field], 8.7

4952, Birthplace, [Scraped from ****pedia], Massapequa
4952, Instagram Followers, [Scraped from *****], 105K

4953, 2004-11-26 14:56, [Automated History], Piercings updated from 'Stash DB' to 'left nostril; Navel'
4953, 2004-11-23 10:01, [Automated History], User Tag added '**** Goat'
4953, 2004-11-21 08:00, [Automated History], 'Example Film X', 'Example Film Y' and 'Example Film Z' added to library
4953, 2004-11-23 10:00, [Automated History], Performer Rating increased from 4.3 to 4.4
4953, 2004-11-23 10:00, [Automated History], Performer Rating increased from 4.3 to 4.4
4953, 2004-11-20 23:59, [Automated History], 'Example Film' Rating increased from 3.7 to 4.1
4953, 2004-11-20 23:59, [Automated History], O-Count increased from 4 to 5 for 'Example Film'
4953, 2004-11-20 23:59, [Automated History], 'Example Film' watched for 56:43:23 (Total Play Duration 7:39:53) on StashAppAndroidTV
4953, 2004-11-20 23:23, [Automated History], Play Count increased from 6 to 7 for 'Example Film' on StashAppAndroidTV

cross-posted to Discord https://discord.com/channels/559159668438728723/642079454054711306/1309991781412114513

Hey, I'm testing this right now and it's looking good. I got inspired with how these fields were being added and was thinking how they could be utilised to track the historical changes of performers (and other types) according to user activity. I think I could probably make a plugin that could write certain events from logging or other detection to this table. If WP thinks this could be part of core functionality, I could work on implementing it with some assists.

I think this is adds an extra level of complexity that I'm not willing to commit to right now, and I'm not convinced that the functionality described (which sounds on the niche side) is worth the extra overhead.