[theme-reviewers] Function submit_button()

Doug Stewart zamoose at gmail.com
Tue Jul 26 03:22:35 UTC 2011


True on the "save your powder for Trac", I'd wager. Perhaps it's my
partial WPTRT rejection for not using checked()/selected() that's
still galling me a bit and, well, that plus "submit_button()" just set
me off. *grin*

I'll have to choose my words for Trac carefully.

On Mon, Jul 25, 2011 at 11:07 PM, Chip Bennett <chip at chipbennett.net> wrote:
> I think those are valid arguments, and I agree with them. But shouldn't we
> take those arguments to Trac or wpdevel or somewhere? From the perspective
> of Theme development, I'm simply looking at it as, "core has implemented it
> this way, so here's a heads-up for how we should probably be implementing
> it, too".
> In other words: we're mostly just downstream of core decisions here.
>
> (And feel free to pick on me; I'm pretty thick-skinned. ;) )
> Chip
>
> On Mon, Jul 25, 2011 at 10:00 PM, Doug Stewart <zamoose at gmail.com> wrote:
>>
>> Then let's go the whole way: pass a simple array to a theme options
>> page and have core generate ALL the markup -- everything else is just
>> dalliance.
>>
>> And again, not to pick on you Chip, but the plain meaning of the
>> template tag just isn't, well, *plain* to a non-initiate.
>>
>> Shouldn't it be "print_submit_button()" or "display_submit_button()"?
>> "submit_button()" suggests that it's submitting something related to a
>> button, *NOT* outputting code.
>>
>> On Mon, Jul 25, 2011 at 10:55 PM, Chip Bennett <chip at chipbennett.net>
>> wrote:
>> > I totally agree with the namespacing thing. I wish core would practice
>> > what
>> > it preaches just a bit better with these kinds of functions.
>> > But, my example was intentionally complex. Basic examples are pretty
>> > straightforward:
>> > <?php submit_button( $button_text, $button_type, $name, $wrapper ); ?>
>> > $button_text: button text
>> > $button_type: 'primary' or 'secondary' (actually, quite useful, as it
>> > helps
>> > ensure button style fits WP UI)
>> > $name: name attribute
>> > $wrapper: (boolean) whether or not to wrap button in <p> tags.
>> > So:
>> >
>> > <?php submit_button( "Save Settings", 'primary', 'submit' ); ?>
>> > <?php submit_button( "Reset Defaults", 'secondary', 'reset' ); ?>
>> >
>> > Is all you really need.
>> > And in the first case, you can even get away with:
>> >
>> > <?php submit_button(); ?>
>> >
>> > No need to pass any arguments whatsoever.
>> > If I had to guess, I would guess that the objective here is to abstract
>> > away
>> > as much of the settings form markup as absolutely possible - which is an
>> > objective that I would actually agree with. By abstracting the form
>> > markup,
>> > it becomes MUCH easier to make UI changes in the future, in a way that
>> > will
>> > ensure forward-compatibility for existing code.
>> > Chip
>> > On Mon, Jul 25, 2011 at 9:39 PM, Doug Stewart <zamoose at gmail.com> wrote:
>> >>
>> >> Okay, need to get this off my chest:
>> >> This particular example + the checked()/selected() stuff has been
>> >> driving me batty. They're examples of over-complication on WordPress'
>> >> part when perfectly viable pure PHP/HTML solutions are tried, true,
>> >> tested and far more approachable.
>> >>
>> >> I mean, seriously, look at Chip's code (and not to single him out,
>> >> it's just the only code to point to here): it's complicated and
>> >> unusable/unapproachable without an XRef for the possible arguments. At
>> >> least in the past, a person with PHP experience had a chance to read a
>> >> simple ternary statment (in the case of checked()/selected()) or a
>> >> person with HTML savvy can read the plain meaning of the Submit
>> >> buttons. It's cleverness at the expense of readability/approachability
>> >> and I think it's a mistake.
>> >>
>> >> Plus they're not even namespaced.
>> >>
>> >> Gah.
>> >>
>> >> Just my $.02.
>> >>
>> >> On Mon, Jul 25, 2011 at 12:58 PM, Chip Bennett <chip at chipbennett.net>
>> >> wrote:
>> >> > The submit_button() function is flexible enough to handle resetting
>> >> > to
>> >> > defaults. :)
>> >> > For example, here's my old code from Oenology (note that I pass a
>> >> > "tab"
>> >> > name
>> >> > to the button name attribute):
>> >> >
>> >> > <input name="theme_oenology_options[submit-<?php echo $tab; ?>]"
>> >> > type="submit" class="button-primary" value="Save Settings" />
>> >> > <input name="theme_oenology_options[reset-<?php echo $tab; ?>]"
>> >> > type="submit" class="button-secondary" value="Reset Defaults" />
>> >> >
>> >> > And here's the replacement code:
>> >> >
>> >> > <?php submit_button( __( 'Save Settings', 'oenology' ), 'primary',
>> >> > 'theme_oenology_options[submit-' . $tab . ']', false ); ?>
>> >> > <?php submit_button( __( 'Reset Defaults', 'oenology' ), 'secondary',
>> >> > 'theme_oenology_options[reset-' . $tab . ']', false ); ?>
>> >> >
>> >> > The rendered output is exactly the same in both cases.
>> >> > Assuming that your "reset defaults" functionality looks at the NAME
>> >> > attribute as part of the $_POST data passed to $input, then you're
>> >> > good
>> >> > to
>> >> > go.
>> >> > Chip
>> >> >
>> >> > On Mon, Jul 25, 2011 at 11:44 AM, George Mamadashvili
>> >> > <georgemamadashvili at gmail.com> wrote:
>> >> >>
>> >> >> Hello Chip.
>> >> >> I noticed that function too and liked it, but if theme author what
>> >> >> to
>> >> >> provide "Reset to Default" button, does it still need to be
>> >> >> hard-coded?
>> >> >> I
>> >> >> had no to dig in this function, can we this function for reset
>> >> >> button
>> >> >> too?
>> >> >> Best
>> >> >> George
>> >> >>
>> >> >> On Mon, Jul 25, 2011 at 8:25 PM, Chip Bennett <chip at chipbennett.net>
>> >> >> wrote:
>> >> >>>
>> >> >>> Good morning developers/reviewers!
>> >> >>> Just a note, from something that I noticed being used in Twenty
>> >> >>> Eleven:
>> >> >>> the submit_button() function, which replaces hard-coded form submit
>> >> >>> buttons.
>> >> >>> I would strongly recommend making use of it in Theme Settings Page
>> >> >>> forms;
>> >> >>> as with other "doing things the core-supported way" criteria, I
>> >> >>> would
>> >> >>> expect
>> >> >>> this one to show up in the Guidelines at some point in the future.
>> >> >>> Chip
>> >> >>> _______________________________________________
>> >> >>> theme-reviewers mailing list
>> >> >>> theme-reviewers at lists.wordpress.org
>> >> >>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >> >>>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> theme-reviewers mailing list
>> >> >> theme-reviewers at lists.wordpress.org
>> >> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > theme-reviewers mailing list
>> >> > theme-reviewers at lists.wordpress.org
>> >> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> -Doug
>> >> _______________________________________________
>> >> theme-reviewers mailing list
>> >> theme-reviewers at lists.wordpress.org
>> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >
>> >
>> > _______________________________________________
>> > theme-reviewers mailing list
>> > theme-reviewers at lists.wordpress.org
>> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >
>> >
>>
>>
>>
>> --
>> -Doug
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>



-- 
-Doug


More information about the theme-reviewers mailing list