Skip to:

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5691 closed defect (bug) (fixed)

Field types hardcoded in admin Javascript

Reported by: drkane's profile drkane Owned by: boonebgorges's profile boonebgorges
Milestone: 2.1 Priority: normal
Severity: normal Version: 2.0
Component: Extended Profile Keywords: has-patch needs-testing


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.

Attachments (1)

5691.patch (2.9 KB) - added by boonebgorges 10 years ago.

Download all attachments as: .zip

Change History (9)

#1 @boonebgorges
10 years ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Awaiting Review to 2.1

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

10 years ago

#2 @DJPaul
10 years ago

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.

#3 @boonebgorges
10 years ago

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.

#4 @DJPaul
10 years ago

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).

#5 @boonebgorges
10 years ago

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.

#6 @drkane
10 years ago

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

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

#7 @boonebgorges
10 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

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

#8 @Offereins
10 years ago

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

Note: See TracTickets for help on using tickets.