Widgets, and me thinking aloud

[almonk]

Hi all,

Thinking aloud here about a feature I'd like to see in Processwire, Widgets (or at least this is the name given to them in Wordpress).

Simply put, Widgets are content blocks that the user of the cms can add/rearrange to designated parts of the site. This is really useful for those client who are a little more au fait with computers and want to add little bits here and there.

For example, recently I had a client who wanted to add a Facebook 'like' button into the sidebar of his site (built in PW). In the end I made a 'custom html' field and let him just drop some content in there - but a more user-friendly solution would have been nice.

I don't have much of an idea if this fits well into the PW philosophy, but here's how I think it could work:

• 'Widgets' is created as a module and a field which can be added to templates.
  
• The developer can add the widgets field to the pages/templates he wants to have the functionality available on.
  
• A bunch of 'core' widgets are created (for instance: Youtube video, image, html block etc etc).
  
• These widgets can be added once on a page. So, in the example above, the user could edit the Homepage, add a HTML widget and just paste his code in to the settings.
  

I don't know if this sounds like bloat - but in my mind's eye it could work very nicely alongside all the current PW features...

[almonk]

As a sidenote - I really like the widgets implementation in pyro cms http://pyrocms.com/docs/manuals/developers/creating-custom-widgets

[Adam Kiss]

Hi Al,

few months ago, I had this idea too. What Ryan basically told me (or I realized), was that anything you might need, you sometimes need to step back, and rethink whether it's not only the linguistics which make you need another function.

In this case, possible solution would be:

• create hidden data structure widgets, where are your widgets in template form, e.g. '/data/widgets/fcb_button', where fcb_button is page of template 'widget_fcb_button'
  
• based on your needs you have two options here:
   
• add also 'widget_setup' page, which is widget setup (indeed) for whole site
   
• add field 'widgets' into desired templates, where you'd limit pages you can select (via queries) to parent '/data/widgets/', or templates
  
• have client select pages he/she wants to use
  

Also, the two points can be combined – one 'default' widget setup for whole site and in case that template has defined 'wigets' field, override the default widget sidebar.

Done.

[apeisa]

I build custom "widgets" for lukio.fi site. Very close what Adam described above, I think. It took about 30 minutes from concept to working code. What I built is something like this:

I have one page as a container for all widgets:

/tools/widgets/

I have template for "default" widget. That template has title, summary, link_title and link_url fields. This is only because that site had lot's of that kind of widgets, which have some text and link. I have different kind of widget templates also, one which allows banner image and link. Of course there could be any kind of widgets: most obvious would be just textarea that allows html or youtube widget, which would ask only youtube video id etc..

Then I have "widgets" page field, which I have on my normal templates, like "home", "page" etc.. This is multiselect, so you can choose as many widgets as you want. As you could guess it just allows end user to choose widgets from /tools/widgets/ children.

I have also widgets() function, which is on sidebar of those "home" and "page" template files. That loops all chosen widgets and returns their content. Because there are different kind of widgets, it checks the widget template and outputs the code based on that. So if widget template is "youtube" it returns youtube embed code, but of course adds there the youtube id from fields.

You could also have multiple widget page fields if your site design requires widgets in multiple places. No problems there. And if you are using asmSelect, you can drag and drop widgets to any order you want.

[ryan]

Widgets like they are in WordPress are an entirely different animal than they would be in something like PW. In WordPress, you aren't dealing with anything-goes templates and instead you are dealing with themes. The theme follows an expected format an typically has an area built to contain widgets, among other things. Drupal is the same with blocks. These CMSs are markup generation engines because it's assumed that the various elements (widgets, blocks, modules, plugins) are generating their own markup. In these CMSs you are typically designing the theme for the CMS, rather than having the CMS accommodate your design. You are styling the output of someone else's markup. There are plusses and minuses to this approach. A plus is that you can make assumptions about things like widgets. Another plus is that you can make a lot happen without development (like dragging widgets in WordPress). A minus is that you are locked in by the needs of the theme and you have far less flexibility and control over your output.

PW is a very different tool from WP and Drupal. PW's approach is to provide you with the tools to get to your data easily, and let you decide what you want to do with it in terms of output. With a few exceptions, it isn't going to generate the markup for you, and that's the point. I personally dislike working with tools that generate the markup for me because it always feels like I'm cleaning up someone else's mess rather than creating my own. Most Designer/Developers prefer to create their own markup because it lets you use your skills to accomplish whatever you want to. ExpressionEngine is another tool that operates on this same principle.

Given the above, I prefer to keep PW out of markup generation at it's core. Meaning, I wouldn't ever want widgets/blocks to be a required element of the software, or part of it's base architecture (like WP or Drupal). But I also think that this is a great use of plugin modules, as well as your own development processes. The methods described by Antti and Adam are great ways to make widgets part of your site. And as was described earlier, you can turn any Page into a widget simply by rendering it (and you'd want to make sure your page's template is producing the appropriate output):

echo $pages->get("/widgets/latest-news-list/")->render();  

Still, something like the above really isn't much different than this (with less overhead too):

include("./widgets/latest-news-list.php"); 

That's how you might make your own widgets. But I like the approach of using modules for widgets too, as they are easier to share for people that want them. I wouldn't ever want to start including built-in widgets in the core since that would be directing how you should build your site. But I'm not opposed to at least supporting it in the core for modules. So if you guys think it makes sense to add a base Widget module class in the core (like the Pyro example) that's good with me. In fact, we already do to an extent so I'm not sure it would be much more than this:

abstract class Widget extends ModuleJS {
    abstract public function render(); 
}

Still, good to have a known starting point even if not much to it.

The way you would call it would be the same way you already do for other modules:

echo $modules->get("MyWidget")->render(); 

or maybe something simpler:

echo $widgets->MyWidget->render();

Almonk is this along the lines of what you were thinking, or something different?

[almonk]

Thanks for your detailed feedback all!

Ryan, I completely understand your hesitation concerning markup generating widgets - their implementation in Wordpress is horrible to use at best, and I definitely don't want to see PW going down that route. BUT, as we've also mentioned, reusable snippets of code to do the same old things (maps, videos, twitter feeds etc) can be a real timesaver.

I very much like the idea of supporting Widgets within the core module library - this render() function is something that seems to have eluded me aswell, and looks useful for this kind of functionality.

I'll have a shot and see how I get on.

Cheers again,

[ryan]

While the PW core isn't built around the idea of rendering markup, I don't think there is any problem with other modules filling this need for those that want it. While we've got that now with modules (like Markup modules), we don't have a specific standard as it relates to markup rendering 'widgets'. I think all we need is a class that requires a render() method, so will plan on this to start. Most likely I'll round up the existing Markup modules behind a base Markup class that implements the Module interface, and we'll take it from there... If we need something more specific to widgets, then we'll probably make a MarkupWidget class to serve as a base for those modules.