Settings pages

[Simon Wheatley-3]

I'm about to put in a settings page with only one field in. What a
waste of pixels and a menu item.

Or am I missing something... is there a way to add my field to one of
the existing options page (e.g. Options > Writing)? Without hacking it
in with JS. :)

Thanks in advance.

S


---
Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
Registered office: 7 Malton Av, Manchester, M21 8AT
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 11, 2009, at 7:19 AM, Simon Wheatley wrote:

> I'm about to put in a settings page with only one field in. What a
> waste of pixels and a menu item.
>
> Or am I missing something... is there a way to add my field to one of
> the existing options page (e.g. Options > Writing)? Without hacking it
> in with JS. :)

This is a topic that in the past has had a lot of discussion, but  
little traction.

Two possibilities come to mind as solutions:

1) Allow a hook of some sort that allows a plugin to add a section to  
an "Other Settings" page.

2) Create an interface so that on the "Manage Plugins" page itself a  
plugin can open up a "mini form" below its row that let's users set  
one or two settings.

Another distinction to think about is that between Settings that may  
be changed from time to time, and "set and forget" settings.  A good  
example of set and forget is Akismet.  How many times do you need to  
go in and change your key?

Thus, both 1 and 2 above might be useful at the same time -- 1 for  
settings that change occasionally, and 2 for "set and forget" settings.

Stephen


--
Stephen Rider
http://striderweb.com/




_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

A little pre-emptive clarification:

On Jun 11, 2009, at 7:35 AM, Stephen Rider wrote:

> 2) Create an interface so that on the "Manage Plugins" page itself a  
> plugin can open up a "mini form" below its row that let's users set  
> one or two settings.

Should have said "...can temporarily open...".  For example, a plugin  
might have a "Configure" Action link (e.g. "Configure | Deactivate |  
Edit").  Clicking on the link would cause a little form to appear with  
the plugin's one or two settings.

Do it with Ajax, or sans JS, the Plugins page reloads with the little  
form added (and a # link so you're taken straight to it).

Stephen
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

In WP 2.7 the possibility of adding additional fields to existing settings
pages was added.

Check the function add_settings_field()

http://xref.yoast.com/trunk/nav.html?_functions/add_settings_field.html

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

By the way, somebody should make a new Codex page about that family of
functions.


--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

Oooooh, shiny.

That is most excellent -- I had no idea about this one. Thanks for the  
link. :)

Stephen


On Jun 11, 2009, at 7:53 AM, scribu wrote:

> In WP 2.7 the possibility of adding additional fields to existing  
> settings
> pages was added.
>
> Check the function add_settings_field()
>
> http://xref.yoast.com/trunk/nav.html?_functions/ 
> add_settings_field.html

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Jeremy Clarke]

On Thu, Jun 11, 2009 at 8:55 AM, scribu<scribu@...> wrote:
> By the way, somebody should make a new Codex page about that family of
> functions.

/drumroll

http://codex.wordpress.org/Settings_API

(it was already there, i <3 codex pages with 'api' in the title)


--
Jeremy Clarke
Code and Design | globalvoicesonline.org
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Simon Wheatley-3]

On Thu, Jun 11, 2009 at 2:19 PM, Jeremy Clarke<jer@...> wrote:
>
> http://codex.wordpress.org/Settings_API
>
> (it was already there, i <3 codex pages with 'api' in the title)
>

Genius... if only I'd looked there first! Thanks all.

S


---
Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
Registered office: 7 Malton Av, Manchester, M21 8AT
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Simon Wheatley-3]

On Thu, Jun 11, 2009 at 1:53 PM, scribu<scribu@...> wrote:
>
> Check the function add_settings_field()
>

Between this and the register_settings function (Andrew describes it
here: http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/)
I am absolutely made up. SO much easier to add and deal with settings!

S


---
Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
Registered office: 7 Malton Av, Manchester, M21 8AT
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Ptah Dunbar-2]

If i'm creating an option using the register_setting API, is there a
mechanism for giving it an initial value or should I just keep using
add_option();?

Ptah Dunbar — pt@...
http://ptahdunbar.com


On Thu, Jun 11, 2009 at 9:59 AM, Simon Wheatley
<simon@...>wrote:

> On Thu, Jun 11, 2009 at 1:53 PM, scribu<scribu@...> wrote:
> >
> > Check the function add_settings_field()
> >
>
> Between this and the register_settings function (Andrew describes it
> here:
> http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/
> )
> I am absolutely made up. SO much easier to add and deal with settings!
>
> S
>
>
> ---
> Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
> Registered office: 7 Malton Av, Manchester, M21 8AT
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Simon Wheatley-3]

n Fri, Jun 12, 2009 at 4:03 AM, Ptah Dunbar<pt@...> wrote:
>
> If i'm creating an option using the register_setting API, is there a
> mechanism for giving it an initial value or should I just keep using
> add_option();?
>

I'd be interested in how others do this, I run something similar to
the following on plugin activation:

// Get the option (returns a default if it doesn't exist)
$value = get_option( $name, $some_default_value );
// Then set the option value in case it didn't exist
update_option( $name, $value );

Hope this helps.

S


---
Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
Registered office: 7 Malton Av, Manchester, M21 8AT
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Nathan Rice]

Ptah,
Using add_option is probably your best bet, as there is no theme activation
hook you'd be able to hook to (that I know of). And if you do it in such a
way that add_option is called only when the plugin/theme settings page is
loaded, you won't be adding any extra overhead to regular page loads.

Also, I'm not sure if you're serializing all your options into a single db
field, but if you are (and you should be) then you can do some magic with
wp_parse_args, or (like simon said) use the default parameter with
get_option to use defaults initially, until you can load the defaults into
the database.

Nathan

My Website
http://www.nathanrice.net/

My Twitter
http://twitter.com/nathanrice


On Thu, Jun 11, 2009 at 11:03 PM, Ptah Dunbar <pt@...> wrote:

> If i'm creating an option using the register_setting API, is there a
> mechanism for giving it an initial value or should I just keep using
> add_option();?
>
> Ptah Dunbar — pt@...
> http://ptahdunbar.com
>
>
> On Thu, Jun 11, 2009 at 9:59 AM, Simon Wheatley
> <simon@...>wrote:
>
> > On Thu, Jun 11, 2009 at 1:53 PM, scribu<scribu@...> wrote:
> > >
> > > Check the function add_settings_field()
> > >
> >
> > Between this and the register_settings function (Andrew describes it
> > here:
> >
> http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/
> > )
> > I am absolutely made up. SO much easier to add and deal with settings!
> >
> > S
> >
> >
> > ---
> > Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
> > Registered office: 7 Malton Av, Manchester, M21 8AT
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers@...
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Ptah Dunbar-2]

Thanks for the tips NR. I was already afraid of that after snooping around
the core a little bit more. And yes, everything's going into one fat array
(you wouldnt catch me dead adding options all over the place).

Although I'm still curious as to what add_option_whitelist() does... Haven't
played with it yet.

In the meantime, I've been cooking up a function to address the non-having
theme activation hook problem:
add_action( 'admin_init', 'framework_activation_hook' );
/**
 * Set the activation hook for the theme
 *
 * @internal not bulletproof, but it'll due until this patch gets applied:
 * @link http://core.trac.wordpress.org/ticket/7795
 *
 * @since 0.4
 */
function framework_activation_hook() {
 global $theme_data;
 $current_theme = get_option( 'current_theme' ); // variable stores the
current theme
 $target_theme = $theme_data['Title']; // variable stores the theme we want
to target
 if ( isset($_GET['activated']) && $current_theme == $target_theme ) {
do_action( 'theme_activation_hook' ); // Available action:
theme_activation_hook
 }
}

So when the user clicks to activate the theme, developers can hook
into theme_activation_hook and call an install function.
Of course this only works when the user activates the theme via the admin
panel, so it's not bulletproof yet. Plus if the page gets refreshed, the
hook gets called again. Lots of holes, but I'm still working on a better
implementation.

Ptah Dunbar — pt@...
http://ptahdunbar.com


On Fri, Jun 12, 2009 at 11:33 AM, Nathan Rice <ncrice@...> wrote:

> Ptah,
> Using add_option is probably your best bet, as there is no theme activation
> hook you'd be able to hook to (that I know of). And if you do it in such a
> way that add_option is called only when the plugin/theme settings page is
> loaded, you won't be adding any extra overhead to regular page loads.
>
> Also, I'm not sure if you're serializing all your options into a single db
> field, but if you are (and you should be) then you can do some magic with
> wp_parse_args, or (like simon said) use the default parameter with
> get_option to use defaults initially, until you can load the defaults into
> the database.
>
> Nathan
>
> My Website
> http://www.nathanrice.net/
>
> My Twitter
> http://twitter.com/nathanrice
>
>
> On Thu, Jun 11, 2009 at 11:03 PM, Ptah Dunbar <pt@...> wrote:
>
> > If i'm creating an option using the register_setting API, is there a
> > mechanism for giving it an initial value or should I just keep using
> > add_option();?
> >
> > Ptah Dunbar — pt@...
> > http://ptahdunbar.com
> >
> >
> > On Thu, Jun 11, 2009 at 9:59 AM, Simon Wheatley
> > <simon@...>wrote:
> >
> > > On Thu, Jun 11, 2009 at 1:53 PM, scribu<scribu@...> wrote:
> > > >
> > > > Check the function add_settings_field()
> > > >
> > >
> > > Between this and the register_settings function (Andrew describes it
> > > here:
> > >
> >
> http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/
> > > )
> > > I am absolutely made up. SO much easier to add and deal with settings!
> > >
> > > S
> > >
> > >
> > > ---
> > > Sweet Interaction Ltd is Registered in England/Wales, no. 6610741
> > > Registered office: 7 Malton Av, Manchester, M21 8AT
> > > _______________________________________________
> > > wp-hackers mailing list
> > > wp-hackers@...
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers@...
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"Ptah Dunbar" <pt@...> wrote:
> Thanks for the tips NR. I was already afraid of that after snooping
> around the core a little bit more. And yes, everything's going into
> one fat array (you wouldnt catch me dead adding options all over
> the place).

Something to consider. "Never" shouldn't be a hard and fast rule.  If you are storing record IDs or other items that can be used to uniquely identify a record you should consider putting them in their own option, especially if the information would be needed as a linking table in a SQL query.

As a case-in-point NextGen Gallery stores most options in "ngg_options."  One of the thing NGG stores in ngg_options is which galleries are part of which albums. My client wanted to display the albums in descending order of those that had the most recently added photos. It was completely impractical from a performance perspective to do it in PHP and not possible as delivered to do it in SQL.  

OTOH, had NGG used separate option entries for each album which violates NR's rule it would have been practical to do in SQL. For example, assuming album_id=7 had three (3) galleries with ids of 2, 5 & 17:

update_option('ngg_galleries_for_album_7','2,5,17');

Then I could have used the following SQL to get a list of photos in reverse chronological order:

SELECT a.id,a.name, g.gid,g.name, p.*
FROM wp_ngg_album a
INNER JOIN wp_options o ON CONCAT('ngg_galleries_for_album_',a.id)=o.option_name
INNER JOIN wp_ngg_gallery g ON FIND_IN_SET(g.gid,o.option_value)
INNER JOIN wp_ngg_pictures p ON g.gid=p.galleryid
ORDER BY p.imagedate DESC

So even though most of the time you should put all options into one array you shouldn't ALWAYS do it that way. As with anything you should consider the situation and potential use-cases before deciding what makes the most sense.  IOW, "Always put all options in a serialized array" should be more of a guideline than a rule.

Just so you know how I solved it I had to hack NGG to include a linking table for "album_galleries" and I had my hacked version of NGG update that table right after it updated ngg_options. Here's a SQL query that shows how it worked (note it's much cleaner than the wp_options version above):

SELECT a.name, g.name, p.*
FROM wp_ngg_album a
INNER JOIN wp_ngg_album_galleries ag ON a.id=ag.aid
INNER JOIN wp_ngg_gallery g ON ag.gid=g.gid
INNER JOIN wp_ngg_pictures p ON g.gid=p.galleryid
ORDER BY p.imagedate DESC

FWIW, it's often better especially for performance to do it with a linking table than to put in the options table the way I suggested.  OTOH, there is conceptual and maintenance overhead to adding tables so sometimes it's just better put into the wp_options table rather than have tens of simple linking tables cluttering up the database.

But whatever the case for plugin/theme developers who've not had experience with relational database 3rd normal form having a rule that says "Always put all options in a serialized array" can result in doing so just because it's "a rule" instead of considering the use-case (see Wikipedia for "cargo cultist.") When that happens the plugin/theme author paints their user into a nasty corner and forces them to hack it up, as I had to do with NGG.

HTH.

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins

P.S. BTW, I keep meaning to send Alex Rabe my updates to NGG for hopeful inclusion in his next version.  Alex, are you on this list?
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Nathan Rice]

Mike,
You're obviously right ... there are always exceptions to the rules, and in
the cases you described, there is obvious need for multiple entries in the
options db.

But for most, we're talking about very simple data (boolean, ID arrays, html
code, etc.) that would never warrant multiple entries in the options db.

Sorry, didn't mean to indicate that there was never a reason to use multiple
entries.

My Website
http://www.nathanrice.net/

My Twitter
http://twitter.com/nathanrice


On Sat, Jun 13, 2009 at 6:32 AM, Mike Schinkel
<mikeschinkel@...>wrote:

> "Ptah Dunbar" <pt@...> wrote:
> > Thanks for the tips NR. I was already afraid of that after snooping
> > around the core a little bit more. And yes, everything's going into
> > one fat array (you wouldnt catch me dead adding options all over
> > the place).
>
> Something to consider. "Never" shouldn't be a hard and fast rule.  If you
> are storing record IDs or other items that can be used to uniquely identify
> a record you should consider putting them in their own option, especially if
> the information would be needed as a linking table in a SQL query.
>
> As a case-in-point NextGen Gallery stores most options in "ngg_options."
>  One of the thing NGG stores in ngg_options is which galleries are part of
> which albums. My client wanted to display the albums in descending order of
> those that had the most recently added photos. It was completely impractical
> from a performance perspective to do it in PHP and not possible as delivered
> to do it in SQL.
>
> OTOH, had NGG used separate option entries for each album which violates
> NR's rule it would have been practical to do in SQL. For example, assuming
> album_id=7 had three (3) galleries with ids of 2, 5 & 17:
>
> update_option('ngg_galleries_for_album_7','2,5,17');
>
> Then I could have used the following SQL to get a list of photos in reverse
> chronological order:
>
> SELECT a.id,a.name, g.gid,g.name, p.*
> FROM wp_ngg_album a
> INNER JOIN wp_options o ON CONCAT('ngg_galleries_for_album_',a.id
> )=o.option_name
> INNER JOIN wp_ngg_gallery g ON FIND_IN_SET(g.gid,o.option_value)
> INNER JOIN wp_ngg_pictures p ON g.gid=p.galleryid
> ORDER BY p.imagedate DESC
>
> So even though most of the time you should put all options into one array
> you shouldn't ALWAYS do it that way. As with anything you should consider
> the situation and potential use-cases before deciding what makes the most
> sense.  IOW, "Always put all options in a serialized array" should be more
> of a guideline than a rule.
>
> Just so you know how I solved it I had to hack NGG to include a linking
> table for "album_galleries" and I had my hacked version of NGG update that
> table right after it updated ngg_options. Here's a SQL query that shows how
> it worked (note it's much cleaner than the wp_options version above):
>
> SELECT a.name, g.name, p.*
> FROM wp_ngg_album a
> INNER JOIN wp_ngg_album_galleries ag ON a.id=ag.aid
> INNER JOIN wp_ngg_gallery g ON ag.gid=g.gid
> INNER JOIN wp_ngg_pictures p ON g.gid=p.galleryid
> ORDER BY p.imagedate DESC
>
> FWIW, it's often better especially for performance to do it with a linking
> table than to put in the options table the way I suggested.  OTOH, there is
> conceptual and maintenance overhead to adding tables so sometimes it's just
> better put into the wp_options table rather than have tens of simple linking
> tables cluttering up the database.
>
> But whatever the case for plugin/theme developers who've not had experience
> with relational database 3rd normal form having a rule that says "Always put
> all options in a serialized array" can result in doing so just because it's
> "a rule" instead of considering the use-case (see Wikipedia for "cargo
> cultist.") When that happens the plugin/theme author paints their user into
> a nasty corner and forces them to hack it up, as I had to do with NGG.
>
> HTH.
>
> -Mike Schinkel
> Custom Wordpress Plugins
> http://mikeschinkel.com/custom-wordpress-plugins
>
> P.S. BTW, I keep meaning to send Alex Rabe my updates to NGG for hopeful
> inclusion in his next version.  Alex, are you on this list?
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 13, 2009, at 5:32 AM, Mike Schinkel wrote:

> "Ptah Dunbar" <pt@...> wrote:
>> Thanks for the tips NR. I was already afraid of that after snooping
>> around the core a little bit more. And yes, everything's going into
>> one fat array (you wouldnt catch me dead adding options all over
>> the place).
>
> Something to consider. "Never" shouldn't be a hard and fast rule.  
> If you are storing record IDs or other items that can be used to  
> uniquely identify a record you should consider putting them in their  
> own option, especially if the information would be needed as a  
> linking table in a SQL query.

Absolutely. :)

I've been a strong advocate of combining option into arrays (in fact  
wrote a details article on doing just that*); but there are definitely  
times when it makes sense to break out certain settings into their own  
entry -- especially when a certain range of settings fall into a  
distinct group.  Of course there are also times when it shouldn't be  
in the Options table at all, but instead may be a field added to an  
existing table, or even an entirely new table.

Stephen

* maybe somewhat outdated as of WP 2.8, but... http://striderweb.com/nerdaphernalia/2008/07/consolidate-options-with-arrays/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

If we're on the topic, I wrote a class that manages an array of options, as
part of my plugin toolkit <http://scribu.net/wordpress/scb-framework>.

You can see the code here:

http://plugins.trac.wordpress.org/browser/scb-framework/trunk/classes/Options.php

I guess I should be writing a proper tutorial for it, but I'm lazy.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Heiko Rabe]

scribu :

> If we're on the topic, I wrote a class that manages an array of options, as
> part of my plugin toolkit <http://scribu.net/wordpress/scb-framework>.
>
> You can see the code here:
>
> http://plugins.trac.wordpress.org/browser/scb-framework/trunk/classes/Options.php
>
> I guess I should be writing a proper tutorial for it, but I'm lazy.
>
>  

You proposal only fits to WordPress running with PHP >= 5.0 and all
installations using PHP 4 versions will not work.
If this should become anykind of common use, that 2 potential options
have to be clarified:

    a) WordPress (Automattic) have to announce immediatly that latest
with WP 2.9 PHP 5 will be required (mus have)
    b) we have to ensure backward compatibility with PHP 4

I know, thats not your decision and not my but in my optinion it's
necessary to state very early that upcomming next WP versions will only
support >= PHP 5.

regards

Heiko
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

>
> You proposal only fits to WordPress running with PHP >= 5.0 and all
> installations using PHP 4 versions will not work.
>

Yes, I'm aware of that. Should have mentioned it upfront.

If this should become anykind of common use, that 2 potential options have
> to be clarified:
>
>   a) WordPress (Automattic) have to announce immediatly that latest with WP
> 2.9 PHP 5 will be required (mus have)
>   b) we have to ensure backward compatibility with PHP 4
>

Although I would love WP 2.9 to drop PHP 4 compatibilty, it's not likely.

As for the second option, I have no intention of pursuing it. There's also
the WPlize <http://wpengineer.com/wplize-a-class-for-options-in-wordpress/>class.


--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

WP 2.9 I believe is moving the requirement up to PHP 4.2.

Please let's not have a long argument about the whys and wherefors

Stephen
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers