[wp-hackers] Idea: Widgets as custom post types

[Stephen Rider]

On Mar 5, 2010, at 9:55 AM, Matt wrote:

> The content vs. structure argument can go both ways. Text widgets contain
> *content* that you manage through WordPress. Before this discussion spirals,
> I agree that wp_posts isn't the best place to put widgets.
> 
> My point from earlier was that I'd prefer them *not* be stored as a big
> serialized string.
> 
> Widgets don't really fit into the posts table (as you and Otto mentioned),
> and I dislike the possibility of wp_posts columns being re-purposed to store
> data it wasn't meant to handle. Creating a wp_widgets table sounds
> reasonable.
> 
> BTW, since you're adamant against storing structure in wp_posts, what are
> your thoughts on how the new menu system stores its data?

I guest the question to me becomes: Why are we so afraid to add to the database when appropriate?

It's like I said in another thread:  think of the site coding "separation" rule:  HTML for structure, CSS for appearance, JavaScript for behavior.  When you try to cram all of it straight into the HTML (font tags et al) it becomes a huge mess to work with.

I see similar problems with trying to shoehorn every possible piece of the site into a category that doesn't really fit (e.g. non-content as content).

That being said, others on this list are probably more experienced coders than I am.  But perhaps that in itself speaks to the danger of getting **too close** to the code so that it becomes difficult to step back and see it from the perspective of someone approaching it as new.  The more it's all abstracted, the harder it is to learn and work with.  Just because we're all so close to it, we may make it easier for us but make it a lot harder for new people to approach it.

I found WP *extremely* approachable when I was new to it, whereas having to work with Drupal ("everything's a Node!") is frustrating and confusing.

I would be perfectly happy to see a "widgets" table and a "menus" table, so that people trying to figure out what's going on under the hood can do so easily.  Abstracting things too far makes things far to arcane to be readily approached by anyone but dedicated professionals, which equals saying goodbye to a good number of tomorrow's plugin coders.

I'd rather separate the tables and abstract the functions a bit more (with wrapper functions as needed for both clarity and ease of use).  For a prime example of that I can point to the get_file_data() function that I submitted to WP 2.9 -- now used by both get_plugin_data and get_theme_data.  We could abstract the functions to deal with different tables if necessary, and wrap them in seemingly table-specific functions

...or something.  Not claiming the "detailed fix" here -- just throwing out the idea.

Stephen

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