Support » Your WordPress » XF:wpt – Preliminary Development

  • 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:

    • Base
      • Options:
      • 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
      • Options:
      • 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
      • Options:
      • 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
      • Options:
      • 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
      • Options:
      • 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
      • Options:
      • 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.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Wow looks sophisticated and smart. Have you shared it on “Advanced” section of WP forum?

    Thank you isaacyassar.

    No I have not shared in the advanced section, but now that I have posted here, I would feel kind of cheap to just re-post again there. I guess I am requesting if this topic may be moved to the advanced section?

    I am making a lot of progress on the framework. I am working on the Widget Group editing, it seems to be the most complicated, but I am trying to set it up with all it’s complications to be more easily updated if WordPress decides to change the widget admin page logic.

    I also changed overall to a plugin architecture and added a condition to the theme to not re-instantiate the global. I’m thinking I will probably release as three downloads, plugin, theme, and plugin/theme.

    I am also trying to get the php docblocs more refined. I may or may not include documentation with the initial release, I guess it really depends on whether I am getting tired and just want to release it. Really though, this would be my first major open-source release as a developer, and would like to put my best foot forward.

    I have a lot of ideas with this framework and don’t really know where to stop with the first release. I’m thinking about importing exporting of settings, additional mods, more admin pages for complete theme management of styles, scripts, and widgets, and finally context management with widgets and templates. Contexts being how to display what you want to when you want to. I’m not sure if I want contexts to bypass templates and use WP_Query directly, or stay template based since contexts are essentially already there. This means load this on “is_single()”, or load this on “single.php”. I haven’t decided what can give more and understandable control.

    Here is a link to a page on my blog:

    Here is a link to the first screen shot, this is an example of 2 WPT widgets:

    This project has been completely replaced by my ongoing project of Extensible Widgets.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘XF:wpt – Preliminary Development’ is closed to new replies.