In the past I’ve mentioned a very complex plugin named “WidgetPress”, which I built and is the underlying foundation of the Sears Community and Kmart Community sites. What WidgetPress does is complex, and the short time I had did not allow me to really clean it up the way I would have liked to. This is why I have not released it publicly.
However, the lessons learned from WidgetPress are many, and some of the ideas and solutions that led to its completion can be feathered out of the bulky plugin into their own stand-alone plugins. Thats exactly what I am trying to do now. The specific functionality I’m working on right now is the idea of using custom post types and taxonomies in such a way that they are no longer independent. It will take some explaining to show how this is useful so I will start by explaining how it is used in WidgetPress.
WidgetPress, at the end of the day just lets admin’s create “Section Fronts” based on category or a Page – define their layout, and drop widgets into them to determine the entire contents of that layout. The widgets themselves make up as much of the page as the theme developer likes – for our purposes, everything between the top navigation and the button navigation is entirely composed of widgets on almost every single page on the site.
For WidgetPress to work, I actually had to completely deconstruct and reengineer the way WordPress handles widgets internally. I completely bypass WP_Widget_Factory, I ignore all those horrible global arrays, and hijack the whole widget registration process. I built my own entire structure for handling widgets, while still allowing (most) normal WordPress widgets to function without a hitch. I could write a whole book about the reasons I had to rebuilt all this but I’ll skip that. In my implementation Widgets are actually a post type, and sidebars are constructed using a custom post type AND a custom taxonomy working together – not in the typical way posts and categories work together – instead the post type and taxonomy function as a single entity. When an admin creates a sidebar, in the background it creates a new post of that post type, and a new term for that taxonomy.
The flexibility this allows is not immediately obvious. Widgets being a post type mean that they exist independent of their actual sidebar. Sidebars being a taxonomy means widgets can be placed into any number of sidebars, and sidebars can be associated with any number of “Pages”, “Posts” or other post types registered for that taxonomy. Sidebars, being a taxonomy and a post type, means that although they are used primarily as a taxonomy – each term can actually store meta data! This is the functionality that today I am building into a separate component.
The project I’m doing this is completely different from WidgetPress, its actually for an in-house products plugin – the intention being that any bit of data about each product can easily be made to be meta data and/or a taxonomy term.
The working name for this is WP_Node. I realize “node” has all sorts of existing meanings and connotations. However, given the way this merges content and relationships, blending them into a single idea – I find it difficult to think of a term that fits it better while remaining as abstract as it should be.
Hopefully in the coming months I’ll be able to release WP_Node (or whatever I end up calling it), as an independent library or plugin. There are also several other very interesting things I’d like to pull out of WidgetPress – maybe at the end of all this I can rebuild WidgetPress using the separate components (each of which will be better thought out and better written).
The Simple Hook Widget just got a little bit less simple.
Since I released this originally, it seems people have a hard time understanding what this plugin could possibly be good for. I can understand that given the vague nature of it being a plugin for hooks.
Additionally, there is a signficant security problem in having this plugin turned on for a server where other non-developers have access to the widgets panel – primarily thats because this plugin lets you do ANYTHING !! Including the use of hooks that are part of core, and could cause serious problems if they are run at the wrong time (such as in the sidebar.
This update introduces the ability for developers to provide an array of hooks, and have those hooks show up as a drop down menu in the widget. Additionally, there is another hook which allows for a default value for that hook.
There is also a complete example packaged with this plugin, for how to setup your own list of hooks, how to set a default, and an exceedingly simple example of how to actually do something with a chosen hook.
Have fun, and please please please be CAREFUL using this plugin.