[wp-hackers] Per-page Widget Settings

[Otto]

You won't be able to accurately do separate widget options anyway,
since each widget can store their own options anyway they like (in the
options table seems to be the best bet). So I'd give that a miss for
now and stick with widget arrangement, since that's the most requested
functionality (the ability to hide certain widgets on certain kinds of
pages).

And ugly custom fields are already used internally elsewhere for lots
of things. Look at _enclosure, for example. Use a key starting with an
underscore ("_sidebars_widgets_post" for preference), because the
underscore seems to be the standard for internal/automatic custom
field usage. A patch can be made to hide these underscore fields from
the interface if it's determined that that is a good idea.

So, yes, stick to a custom field in postmeta, for per post/page settings.

Also, use a fallback mechanism similar to the template hierarchy. If a
single post/page has no custom field for the widgets, fallback to the
one for all single pages (perhaps stored in the options table).
Failing that, fallback to the default widgets layout. Same for
archives and anything else. Store the "generic" layouts in the options
table, with names of "sidebars_widgets_archives" and
"sidebar_widgets_search" and such. The default is already there as
"sidebar_widgets".


On 5/31/07, Jairus Pryor <jairus at gmail.com> wrote:
> On 5/31/07, Austin Matzko <if.website at gmail.com> wrote:
> On 5/31/07, Jairus Pryor <jairus at gmail.com> wrote:
> > > I'm developing a plugin which would allow you to define your widget
> > > layout/options on a per page/post setting (as per TRAC ticket #4280),
> > > and I thought I'd ask for feedback before I make any structural
> > > decisions. What I'm thinking:
> > >
> > >
> > > *Storage
> > > New table, say wp_postext
> > > Fields:
> > >  post_id (BIGINT 20) primary index-> for storing which post this
> > > setting belongs to
> > >  widgets (TEXT) -> for storing which widgets are available, in a
> > > serialized array (similar to active_plugins in wp_options)
> > >  widget_options (TEXT) -> for storing options for the widget, in
> > > serialized array
> >
> > Why don't you use the postmeta table instead of creating a new table?
>
>
> To store into post_meta, we'd need one row for the active widgets and
> their order. and a second row for the options of the widgets.
> That means 2 integers and 2 meta_keys would have be added OVER what
> would be required if we were using a new table.
>
> Also, post_meta is used to store the custom values as well... not many
> users would want to see two custom fields of serialzied arrays in
> every post.
>
> Jairus
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>