What are widgets?

Widgets, in the case of b2evolution, are basically skin tag plugins, like the weather plugin; ministats plugin; calendar plugin; and all the others that you normally have floating around in your sidebar. Currently if you want to rearrange the order in your sidebar, or add a new skintag plugin, you have to crack open your skins _main.php and manually add a snippet of code wherever you want the results to be shown.

This method of course has a couple of flaws when it comes to reality. The main flaw it has is that it requires a slight knowledge of php, not a lot but often it's enough to trip up the basic user. The other main flaw is that it requires the ability to be able to ftp files to the server. In a multi blogger environment I'd be very surprised if more than a couple of chosen users had ftp access at all.

This is where widgets come in. From version 2.0 skintag plugins have become Widgets and they work in a very different way, although they're still plugins at heart and can still be added to a skin in the old school way. With widgets, and an appropriate skin that uses them, you no longer need to edit your template to change the order, or even to add new ones, or delete ones you no longer use. Now you can do all that from admin. With a few clicks of your mouse button you're able to add and remove widgets, change their order of appearance, and even choose where they appear in your skin.

The advantages of widgets

The advantages to the basic user are obviously huge, they no longer need to know any php, they don't need ftp access, they don't even have to know what a parameter is. All they need to do is wander over to the admin area for their blog and click buttons, how simple is that! There's also other advantages, skin designers no longer need to think about every possible plugin that might get installed. It's all taken care of for them so all they need to do is to add "containers" to their skin, which is basically a place holder for widgets to fill. Widget designers no longer need to say "crack open your skins _main.php and paste this code snippet wherever you want the answer to appear", which should save a fair few support requests and crashed blogs.

It all sounds to good to be true huh? Simple enough for even the basic users to be able to use, convenient for skin designers who no longer have to worry about what plugins should go where and in which order, and great for blog admins who no longer have to give out ftp accounts to users so they can change their skin.

The problem with core widgets

There's absolutely nothing wrong with the core widgets, as long as you want to use their default output. A prime example is the rss widget which has a hard coded title, part of which is that groovy little orange icon. Unfortunately that groovy little icon has a white background instead of a transparent one which meant it looked bloody awful on a pink skin I was playing with ( don't worry, I won't assult your eyeballs by linking to it ). Now for me that's not a huge problem, I have CVS access so I can convert the background to transparent and upload it to the core for all future versions.

The problem is, I don't actually want the icon in the title for my skin. In this instance, because the title is hard coded, I'd now have to hack a core file to remove the icon, ohhh, and it'd be removed for all of the skins. Now, I've not wandered through all of the core plugins to see if they're equally hard coded, but lets pretend they're not. Lets imagine that I could call the rss widget in my skins _main.php in the old school way, and pass it the title that I want it to use. Great, now I can remove the icon for just the skin(s) I want, so no problem right? ........ Wrong. The moment you put a skintag call in instead of using it as a widget you lose the ability to put it where you want in your sidebar, unless you put all of the widgets in as skintag calls, in the order that you want them. Which kind of defeats the purpose of having widgets in the first place, so now were back to square one

The only real solution to this is to go through the code for all of the core widgets and to convert all of the hard coded values into settings which can be changed on a per blog basis. This would at least allow the user to change the values to something that suits their needs. Although it would also be nice to have widget settings on a per skin basis, this would probably be overkill

Summary

I think users and admins are going to love widgets. For the user they get far more control of how their blog looks without having to worry about how to add it to a skin without breaking the skin. The admin advantage is even clearer, no longer do they have to consider either giving users an ftp account so they can alter their own skin, or making the changes for the user, or just telling them "tough shit, that's the way the skin looks". The other bonus for them is they no longer need to change every skin just to install a new plugin.

From the skin designers point of view, there's no longer the need to either try and code for every plugin out there, and ones that might be out there in the future, or if they're anything like me, code for all the plugins I use and sod the rest Now they can create a skin that has the basic skintag parameters, and put a container wherever a user *might* like to have a widget .... hell, they could add one to each and every <div> and give the user complete freedom of choice.

For widget developers it's just made the documentation easier, "click install" is pretty simple to explain, and, if they use parameters well enough they should also be able to cover any skin / situation. Another bonus will be the reduction of "I tried to install the 'foo' plugin, but when I added the php to my skin it didn't work / looked wierd / went tits up / some other reason" support questions to answer.

All in all I think that widgets, like many other things in 2.0, are a great step forward for every part of the user base, from the basic user, to blog admins, to skin designers to plugin developers..... mind you, that's probably why it's version 2.0 and not 1.11 huh?

¥