WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#12354 assigned enhancement

WP_WidgetArea class

Reported by: jimisaacs Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Widgets Keywords: widgets dev-feedback
Focuses: Cc:

Description

After a short discussion involving the state of the Widget API within another ticket's comments, it was proposed to me to create new ticket on this subject.

The idea is that in updating the Widget API, like the WP_Widget class, widget areas will have a similar registry structure.

In my opinion though, I believe that for backwards compatibility it should be integrated but remain separate from the current API for controlling sidebars, also like the WP_Widget class.

In the previous discussion, I said that a possibility could be creating a WP_WidgetArea class, and a WP_WidgetArea_Factory class to register and unregister them.

After some thought though, I believe this is pretty much unnecessary.

What is a widget? - It is a GUI module with a client-side and administrative view, wrapping how to control, use, and display data.

It is a form of MVC, and that's basically it! That being realized, I don't see a problem with adding one more default widget to the core:

WP_WidgetArea extends WP_Widget

This will allow dynamic generation of widget areas. Implementing how to edit these areas within the current interface is another story, though I have a kind of hacked logic I am unhappy with working in a released plugin of mine.

In the future, using widgets for widget areas will eventually depreciate the entire sidebar API. It would only depend on one global area to add and pull widgets from (the theme... cough...).

Also, with custom post types now becoming more prevalent, and this is just my imagination talking, widgets could become another form of the post object:

post_type = widget

Change History (11)

comment:1 nacin4 years ago

  • Milestone changed from 3.0 to Future Release

Other ticket: #11160. Thinking this should be future release for now, no real chance building new widget infrastructure in the next few days.

comment:2 Denis-de-Bernardy4 years ago

  • Cc Denis-de-Bernardy added

comment:3 jimisaacs4 years ago

Just wanted to give an update... sorry for the long comment.

I've been exploring a lot of possibilities with widgets in general; what they are, what they do, and what they should be.

I have come to the conclusion that they are UI specific of course, and hence also PHP specific. This means I am starting to really wonder if they deserve any sort of data structure within the database, and instead take on a more modular PHP hierarchy. I have been contemplating this because I really hate having to make unnecessary database calls for hundreds of widget options when they might not even be used on the page, while on the other hand the widget might be rendered anywhere at anytime within any URL.

Having all this brainstormed, I am going to try to implement this modular structure into my plugin first, before I actually propose it for the core. Better to test there anyway to actually see if it is an architecture worth pursuing.

What I am going to do is make widgets into modules. These will be represented as directories in specific, though any number of locations. The widget load locations, is the base of plugin hooks being that a dev can hook into an modify where widgets are located and loaded from. Within these locations will be directories matching what is now the id_base of the widget hence identifying the module. Within each one of these directories will be a common structure for all widgets following the MVC pattern, so essentially overall widgets will become a UI only based HMVC implementation.

I haven't decided entirely on the inner directory structure. What I've got so far is a conf/ directory, models/ directory, controllers/ directory, and views/ directory. Within the conf/ directory will be config PHP files that are nothing more than files of arrays. I haven't decided if these files will return their values directly as a function value or define their arrays explicitly and be loaded by a reference to their variable names. The models/ directory may be the same as the conf/ directory defining the fields or settings of the widget, or a class to modify and define them. The controllers/ directory would be a place to store more complicated functionality of the widget, but right now I was only thinking of it as the place to store the actual widget class itself which in this architecture would be the only bridge from the module to the widget API as a whole. The views/ directory is pretty self explanatory, but I did think it would need to contain 2 view PHP files at minimum, a default.php view for the front-end, and an admin.php view for the controls in the backend. Of course more views depending on the complicated nature of the widget could be added, but these views are the minimum needed for a widget's UI.

So overall what does this accomplish? First off, it negates the complete necessity of saving every single thing about a widget in the database because it provides an organized file structure where simple PHP array scripts may be saved and edited with ease. This opens the widget API up to more customizations and understanding. It also defines an explicit structure for developers to follow while allowing their plugins to be much more accessible to other developers... and so on.

Well this is where my thought process has taken me on this brainstorm. I'll continue working it out.

comment:4 jimisaacs4 years ago

I have stopped working on this currently until the official release of 3.0
I want to see what all the new might be available.

comment:5 rspindel4 years ago

  • Cc rspindel added

comment:6 jimisaacs4 years ago

Well it is time to get back to thinking about this since the release of 3.0. I've had a look through the new concepts with joining of the multisite, the drop-in caching functionalities etc.

It looks as though WordPress is trying to become more of a base platform to build from, this combined with my new admiration of hiphop php it is changing my thought process on setting up widgets completely through a modular directory structure.

Instead, the object oriented structure of the Widget's codebase should be the only thing to remain modular. It should allow for different views on the front-end and admin. The admin should be integrated into the Role/Capability API on a per widget group, per widget, and per widget setting group basis.

What I am thinking about now, is just a better way to relate a widget to a widget group, and a widget group, and each of those to a number of different combinations of WordPress conditional contexts.

To be integrated with Multisite, each widget group needs a relationship to a blog and/or a site. Now there is a choice with such conditionals as is_multisite() to using the a particular blog's tables, or the main site's tables, or the sitemeta table.

comment:7 scribu4 years ago

  • Owner scribu deleted
  • Status changed from new to assigned

comment:8 jimisaacs4 years ago

Common sense hit me in the face again. It's a love hate relationship with me and common sense ;)

Anyway, there is a reason the multisite functionality includes simple conditionals. That way the multisite conditionals can be integrated directly into what ever way I figure out how to relate everything to the conditional contexts that I mentioned before. So in my mind, a person can have the same control for is_home(), is_single(), is_logged_in() as with is_multisite() and is_main_site().

It is nice that all of these conditionals are simple global helpers, but I am wandering if there are plans for the future to make these more dynamic? Is there any talk of maybe allowing access to something like a conditional array or object a developer can just check all in one shot? Or should I continue to think about hardcoding the conditional functions or using them as callbacks?

comment:9 scribu4 years ago

Is there any talk of maybe allowing access to something like a conditional array or object a developer can just check all in one shot?

You can already do something like that yourself:

function check( $conditions ) {
  foreach( $conditions as $key => $value )
    if ( get_query_var($key) != $value )
      return false;

  return true;
}

Usage:

if ( check(array('year' => 2010, 'post_type' => 'foo')) )
  // bar

comment:10 jimisaacs4 years ago

@scribu

Thanks for the tip, I'll look into an implementation like that.

comment:11 sooskriszta5 months ago

  • Cc vivek@… added
Note: See TracTickets for help on using tickets.