I understand there are lot of WordPress "frameworks" out there, and a lot are for specific tasks. Here I wanted to report on my framework that is unreleased. I just wanted to bring it up to see who would be interested in the WordPress development world.
It is actually a package built on another base framework I developed.
The core framework is called the "X Framework", which I developed specifically to be used to integrate functionality into another application.
It is Object Oriented and uses techniques that are not dependent on anything else except PHP 5. It also employs the use of what I call "reference mapping" to keep track of all dependencies built from the X Framework and mapped to another application.
Then on top of this I have a package called WPT (short for WordPress Theme). This is what can be called a sub framework that uses my "X Framework" to keep track of all WordPress dependencies.
The WPT package is used by instantiating one global object, similarly to BuddyPress. All functionality from this object is class based and uses php 5 standards and patterns.
It has it's own sub frameworks for building additional widgets, admin menus and pages, and generic managers for various common tasks.
Everything is Object Oriented and extending classes is how to extend the package into a fork or a top level package used for your specific sites and applications.
It is called WPT, but essentially it can be implemented strictly as a plugin. I only use the Theme's functions.php file to instantiate the global and go from there. This could be achieved of course through a plugin activation hook. I focused on the theme because I think a lot of the functionality I am adding and changing is theme-based. I could be wrong, but I'll find out after and initial release.
What I believe is the most useful piece of functionality to the end user are the widgets created with this framework/package. In particular one widget which is called the "Widget Group", it is essentially a widget that represents a group of other widgets that may be edited through the same admin page as the global registered sidebars. This widget is built the same as the other widgets in this framework. They extend each other, each adding upon the parent's functionality. One of the parent's of the "Widget Group" widget is the "View Widget". This widget can essentially be considered what most people would call a module. It uses a view template specified in the admin and passes any number of parameters to the template. All the "Widget Group" widget does is uses a view to print out the sidebar is represents on demand. This is all very hard to explain, and I know it will be better when I finally get a releasable version. Really what I am saying, is that I've turned widgets into the base MVC modules for an entire theme.
Widgets already included in the package are:
- Title: The title of the widget
- Render Title: Whether to render the title on the front-end or not regardless of there being a title provided.
- Additional CSS Class: This is added to the dynamic widget classes when rendered by a sidebar or widget group.
- View Template: A dropdown list of all template files attributed to that particular widget class or extended widget class. They are defined nearly identically as Page Templates,
/* View Name: My Widget View */
- View Parameters: A query string of parameters parsed and extracted to be available as regular php variables within the view template file.
- Content: This is any content that is a large block of text, html, script, etc.. It is then automatically added to the view parameters and is available just the same in the view template file.
- Date: The same as the "Content" widget, only this data represents a date and is entered that way in the widget's admin controls.
- Query Posts
- Query: This is a post query that is passed directly to a new WP_Query object. This object temporarily overrides the global $wp_query so your view template can look just the same as a regular WordPress theme template, using the "The Loop" as you normally would. If no query is provided, then the global object remains unchanged.
- Widget Group
- Group Name: The name of the group (sidebar) that is registered by this widget.
- Before Widget: register_sidebar argument.
- After Widget: register_sidebar argument.
- Before Title: register_sidebar argument.
- After Title: register_sidebar argument.
- Widgets: This is not editable in a regular sense by this widget's controls. Instead when clicking on the edit button in the controls, you are taken to a new widgets.php page where you may add and remove widgets normally to the registered sidebar represented and registered by this "Widget Group". An alert at the top of the page allows you to go back to the global sidebars and stop editing the current group.
I hope all that made a little sense. As I said it's hard to explain, and I hope to get a release soon. I am just curious and hoping that some developers out there might be as eager to get their hands on it, as much as I am trying to release it.
If you or anyone else is interested drop me a line on my blog.