Field types hardcoded in admin Javascript

[drkane]

In the "Profile fields" admin page (/wp-admin/users.php?page=bp-profile-setup&mode=edit_field&group_id=6&field_id=286), the field types with custom options are hardcoded into the javascript in the dropdown (the "show_options" function in "\buddypress\bp-xprofile\admin\js\admin.js").

As custom field types are now possible this means that when a custom field type is selected, and it presents another option, the selection div for this option is always shown, even when another field type is selected.

I think the solution is to generate a list of all the possible element Ids from the select option, and then hide all of them, before then showing the correct ID.

[boonebgorges]

Good find. Can you please test 5691.patch to see if it solves the problem for you?

[DJPaul]

I hesitate to call this a bug; I left this out of the scope of the 2.0 changes intentionally as there's better ways of doing this in the long-term. I'm not super keen on this approach, but I guess this is OK for now.

[boonebgorges]

DJPaul - I'm curious to know what your "better ways" are. I can imagine more elegant ways, but they require rewriting most of the js that powers these admin pages. If that's what you have in mind, then I certainly think it's worth considering the sort of band-aid fix suggested here, as a rewrite will take a lot of time and thought.

[DJPaul]

Pretty much that; I spent some time thinking about how to re-build the xprofile admin screen in Backbone, and what we'd have to do to get there. I have some wireframes, and some early code on my Github fork, somewhere with ideas.

I think the next step was to set a JSON object for each field type containing a complete dump of information for that type, and then re-write the existing wp-admin JS to build certain parts of the screen from that data (not that dissimilar from what's been proposed in this ticket/patch, for example).

[boonebgorges]

Ah, gotcha. It'd be a cool project to rethink how this interface works (not just in code, but also in terms of the UI, which I've always found confusing). But I'm guessing that this is not pending for 2.1, so I think it's harmless to put in the suggested fix, since as you note, any future system will also list field types dynamically.

drkane - If you get a chance to test the patch, please do let us know if it does the trick for you.

[drkane]

The patch works perfectly - thanks for such a quick fix.

Do I need to change something on the ticket? (not done this much before!)

[boonebgorges]

In 8494:

Generate list of xprofile field types that support options for Field Admin, rather than hardcoding

This change allows custom field types to support options, while using the core
admin panel UI.

Fixes #5691

[Offereins]

Just saying thanks for the fix, as I recently stumbled upon this.