I have not been following development so I apologize for not raising the following inquiry earlier:
What was the advantage of implementing custom fields on a per-performer basis instead of a global basis?
Per-performer basis
I imagine users may find it tedious to recreate the same field repeatedly for each performer that requires it. This may also lead to inconsistent field names, where over time a user goes back to recreate a specific custom field on another performer but accidentally labels the same intended field differently.
Global basis
If it’s not too late to consider the global approach, PornVaults implementation could offer some valuable insights on aspects of implementation and management of custom fields.
If I remember correctly, custom field management was administered within the app’s settings ui. The custom fields would be available to all performers, and appeared seamlessly alongside the other fields.
There may have been a corresponding field attribute that restricted fields to specified genders, but I’m not sure.
The design decisions were detailed in the corresponding issue. The most important point to consider is that the custom field ui isn’t intended to be used frequently by the user. It is intended for manual data manipulation. Custom fields are intended to be used by plugins to provide customised fields and behaviour.
I haven’t yet looked into what PornVault does, but changing the way this works would require a complete redesign and reimplementation of this feature. I’d have to roll back this feature and reattempt it in a later release.
I’m still working on the filter UI stuff, bit perhaps a next step will be to create an example application plugin utilising custom fields.
I’ve yet to take a look at the code, but I’d imagine it wouldn’t be too hard to create a plugin that applies an empty copy of the same custom field to all performers.
Sounds very interesting, I’ll have a gander and see if it would benefit my Performer Details Expanded plugin. If not I’d be happy to come up with some kind of demo plugin.
Understanding technical details is beyond me, but if I understand correctly, it looks like the way you’ve implemented it with the performers_custom_fields table renders my UI/UX concern something quite doable with a plugin.
For example, changing the above field input form into a drop-down select form, and populated with all the pre-existing fields from the performers_custom_fields table, along with the ability to create a new field when a unique value is input in the select form (similar behavior to other dropdown selects).
