-
-
Notifications
You must be signed in to change notification settings - Fork 803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performer custom fields #5487
base: develop
Are you sure you want to change the base?
Performer custom fields #5487
Conversation
These were reported by Tweeticoats and kanaza on Discord but I'm repeating them here for posterity:
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 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? |
5f9008b
to
afe5899
Compare
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 : 4953, Pnalike, [User Field], Princess D*a 4952, Birthplace, [Scraped from pedia], Massapequa table: performer_custom_fields 4953, **** alike, [User Field], Princess D**** 4952, Birthplace, [Scraped from ****pedia], Massapequa 4953, 2004-11-26 14:56, [Automated History], Piercings updated from 'Stash DB' to 'left nostril; Navel' cross-posted to Discord https://discord.com/channels/559159668438728723/642079454054711306/1309991781412114513 |
Adds
custom_fields
field to performers.In graphql, performer create mutation, the
custom_fields
field accepts an object value. For performer update mutation, thecustom_fields
field accepts either afull
value or apartial
value. Thefull
value performs a full replacement of existing custom fields, whereaspartial
will only replace values provided in the input value.Custom fields may currently be either strings or numeric values. JSON objects or arrays are not accepted.
In the UI, custom fields are hidden behind a collapse button and are only shown in the expanded view:
In the new/edit performer views, custom fields are hidden behind a collapse button:
Filtering is available in the graphql interface, but is not currently implemented in the UI. This may be added in this or a separate PR.
Custom fields will be added to other object types in future.