[wp-hackers] Per-page Widget Settings

[Jairus Pryor]

I think we'll be able to do separate widget options with some changes
to the core. Given that, I'm not sure if wp_postmeta (which is storing
quite a bit already) is the best place for it moving forward, or if a
new table for widget options (eg: wp_page_widgets) would be the most
future-proof implementation.

Jairus


On 5/31/07, Otto <otto at ottodestruct.com> wrote:
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
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>