[wp-trac] [WordPress Trac] #28975: Improve do_settings_fields() by including field ID on <tr> table row
WordPress Trac
noreply at wordpress.org
Tue Nov 25 00:04:05 UTC 2014
#28975: Improve do_settings_fields() by including field ID on <tr> table row
-----------------------------+---------------------------------
Reporter: Jonnyauk | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version: 4.0
Severity: normal | Resolution:
Keywords: has-patch close | Focuses: ui, administration
-----------------------------+---------------------------------
Comment (by valendesigns):
@nacin I've updated the patch slightly. Instead of adding the field ID as
a class every time, which is not very extensible, I made it look for the
value of the `class` parameter, which would have been passed through the
`$args` array in `add_settings_field()`. It's the same way `label_for` is
passed around.
I'm not sure whether you still feel this would tie us to the markup. But
if you change you're mind on that front, I think explicitly setting the
class for each element is a better solution.
For example, say you've added a few settings to the profile page and one
of them is to activate and make use of the other settings (something
similar to `show_avatars`). When you activate the main setting it would be
much easier to add JavaScript to toggle the other options visually in the
UI with this patch.
What brought this to my attention, and was why I had planned to create my
own ticket before I found this one, is that Mark created ticket #30168
that would visually toggle the avatar settings. If that patch makes it
into the core and you want to seamlessly add additional avatar settings
that will also be toggled you would need to duplicate his JavaScript. I
noticed this when I was working on a better way to cache Gravatars than
the plugins that are currently available. A whole different issue, but how
I ended up here.
Also, I have a second patch that cleans up that functions PHP and removes
my ternary operator to be more inline with the coding standards, but
figured I would wait to hear back from you first. My first patch is to
highlight the change being requested.
I'm just asking for a reconsideration before this ticket is closed.
Cheers,
Derek
--
Ticket URL: <https://core.trac.wordpress.org/ticket/28975#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list