It’s an idea proposed by Ipstenu that might just work. The gist of her suggestion is to manage widgets similar to how we manage menus. Instead of all that fancy drag and drop stuff, we switch to a check box approach where users can check which widgets they want to have added to a particular sidebar. Judging by the comments left on that post, a number of people feel that her concept is a great idea and should be considered when the time to rework the widget management area arrives. Drag and drop was cool when it arrived but having 3-5 sidebars with 30 available widgets makes drag and drop not so cool anymore. ∞
A Theme With 70 Different Widget Spots
I stumbled across this theme the other day called Tachyon by RocketTheme and noticed that is has 70 widget positions. That is insane. I can’t imagine how much of a burden or a nightmare it would be to manage something like that from the back-end of WordPress as just having 15 or so widgets can become cumbersome. This link will show you all of the various widget spots complete with there variations. Check out the following image which shows a blueprint of where all of the widget spots are located.
Plugin Review – Spots By Interconnect/it
Back on August 25th, the guys over at Interconnect/it released a brand new plugin called Spots. If I had to describe this plugin in one sentence, I’d say it was a text widget on steroids.
There are quite a few things that make this plugin very cool to use. The first is that it uses a custom post type which means when you create a spot, you get access to the editor as if you were writing a post. You also get access to all the stuff that’s normally attached to a post with the exception of tags and categories. Because you get to use the normal editor, it’s very easy to add media to the spots that are created without using blocks of HTML as you normally would within a text widget.
After a spot is created, you can add it to any sidebar that’s built for widgets. However, you’re not limited to using spots in the sidebar only. In the Visual editor for writing posts, there is a Spots button which uses a shortcode to insert the spot into a post or page.
Shortcode Button That Inserts The Spots Shortcode
Developers can also take advantage of this plugin by using the built in functions. For example, instead of hard coding text into a widget within the footer of a theme, you could turn it into a spot which would enable the end user to customize that spot with whatever they want from the administration panel, not having to touch any code. By doing it this way, theme developers could probably get rid of a couple theme options for text areas or default widget areas.
Conclusion:
Spots is an awesome plugin by the crew over at Interconnect/it. People have been wanting WYSIWYG functionality in text widgets since the day they were introduced into WordPress. This plugin does that and so much more. If you’re looking for a replacement for the default text widget in WordPress that provides more flexibility, definitely give Spots a try.
Flexible Widgets – Only Works For Certain Widgets
Those of you who listened to episode 111 of WordPress Weekly or who have been reading this site for a long time realize that I’m on a quest to find a plugin that provides the right interface for making widgets flexible when it comes to configuring when and where they show up. To fulfill this task, I’ve been using Widget Logic but it doesn’t have any interface that allows users to choose where the widget shows up. Instead, it has a small box where you put in a conditional tag.
Today I came across a post by Sarah Gooding of WPMU.org (wonder if she listened to the show) showcasing the Flexible Widgets plugin by bechster. As the name implies, it’s supposed to provide additional display options for widgets to give them more display flexibility. After checking out Sarah’s screenshots and realizing the interface looks like something I’ve been thinking about, I decided to give it a try. Unfortunately, after installation I noticed two problems. The first is that if I have too many pages to fit in the box, the scroll bar for the Pages area disappears. I was able to scroll within that area by placing my mouse cursor in the box and using the mouse wheel but this is not how it’s supposed to work. It should look like the Categories area with a proper scroll bar. I’m using Firefox 3.6.22 by the way.
Scrollbar Is Missing For The Page Box
The second issue I encountered is that the additional display options do not show up for certain widgets. For example, here is what my YARPP widget looks like:
Non Flexible Widgets :(
It also doesn’t work for my KB Advanced RSS widget but it works just fine for all text widgets. If these two issues could be fixed and I can be somewhat guaranteed that the additional display options will work with all widgets, this would be a great plugin to recommend as I love the simple interface for choosing where the widgets will show up. For now, I’ll be going back to Widget Logic. It’s worth noting that the plugin author states: May conflict with themes or plugins which include custom widgets.
Feedback Needed For New Widget Context User Interface
Kaspars Dambis of Konstruktors.com has publised his second version of a proposed user interface design for his popular Widget Context plugin. Widget Context is a plugin that provides users the opportunity to show or hide widgets. I’ve used Widget Context in the past but I’ve been quite happy with the performance and functionality of Widget Logic which relies on me knowing about Conditional Tags. Because of the conditional tags concept, it’s not the most user friendly plugin. However, I am very satisfied with how it works. By default, when a widget is enabled in WordPress, it’s displayed within the sidebar on every page that sidebar is loaded. After configuring a widget through Widget Logic to only show up on the front page via the conditional tag, it is then hidden on all other pages EXCEPT the frontpage. So in a way, I’m configuring where the plugin will display and be hidden at the same time.
Widget Context on the other hand has the ability to tell widgets where they are hidden and where they will be shown. Some may see this as a benefit as more flexibility, but I see it as another layer of complexity. The second edition of the proposed user interface for Widget Context is as follows:
You can also see a live demo of the UX proposal. I like the idea of being able to search for pages or posts to show or hide widgets during the configuration process. However, this version of the plugin implements rules that can have lower or higher power based on their vertical arrangement. While this provides more flexibility, I think it adds complexity. Since this type of functionality looks like it will never make it into the core of WordPress based on everyone that has told me “There’s a plugin for that” I’d like to share with Kaspars and anyone else that may be looking into this realm of WordPress functionality what I’d like to see so that we can have a GO TO plugin that everyone can use.
I’m thinking of a plugin that’s a cross between Widget Logic and Widget Context. This plugin should work on the premise that anytime a widget is added to a sidebar, it’s viewable across the entire site where that sidebar loads. UI is added to the widget screen so that I can easily search or choose from the various template files that make up my theme to decide where the widget will be displayed. By specifically configuring where the widget will be displayed, I’ve also configured where it will not be displayed. I’m not quite sure which user interface would work best for selecting more than one area where the widgets will be displayed, perhaps the check box method that already exists in Widget Context. This is about all I’d need to satisfy my needs. It’s simple, not many options and I think covers the basis for a lot of uses. Now, if Kaspars or users suggested that they wanted rules, or more complex ways of telling their widgets where to show up or hide, I would not complain about having an Advanced tab that showed additional options. But I definitely don’t want that clutter in view as part of the default configuration UI.
I’m not sure if I explained my vision very well but if you could, please take a look at the proposed changes and offer Kaspars some suggestions if you have any.
Widgets, Modules, Or Metaboxes?
A few weeks ago, there was a poll published on PollDaddy.com that asked the question, What do you call these draggable, expandable boxes in WP? For example, “The Publish _________.”. The choices were postbox, metabox, module, widget, area, container, box, or other. I think the poll question was not specific enough with regards to the question or at least, I was pretty confused.
Attached to the poll is a screenshot of the publishing box within the WordPress back-end. This publishing box is called a metabox as are the other boxes in the sidebar on the publishing page. So naturally, I voted for Metabox. However, in WordPress, there are terms used to describe these boxes depending upon where you are. On the front-end of the site, they are called widgets, in the back-end, they are called metaboxes. I think what the poll question should have asked was If you could change the name of widgets or metaboxes, what would it be? Then, I would have voted for Container, Module as I feel those two best represent common sense of their functions. You have a container that holds stuff. That stuff would be modules. Modules imply they can me moved around and are versatile. This can be understood without pointing someone to a Codex page.
On the flip side, it was interesting to see that 26% of the voters just call it Box while there was a 1% difference between Metabox, Module and Widget. I highly recommend reading the comments on that poll to get a feel for why people voted the way they did.
What did you vote and why?
Easy Editable Text Regions
Chris Coyier published a great technique on the Digging Into WordPress site that explains how to create editable regions instead of text areas that are baked into the theme. For instance, ever get a theme with a block that looks like a widget but it’s really just a div container in the sidebar.php file that you manually have to edit? I know I have, a number of times, wishing it were just a text widget I could easily edit. Thankfully, the child theme I’m using for WPTavern.com is chock full of Widget areas so it’s a simple matter of creating a text widget and assigning it somewhere.
Another tidbit worth noting here is that in the example, the specific widget has a unique id number which you can assign a class too and thus, style in CSS. So in essence, you could give each text widget its own style. It would add more CSS to the themes CSS file but it might result in some cool outcomes.
Kaspars Adds Widget Context To Plugin Repository
Kaspar’s has announced on his blog that he has finally added his Widget Context plugin to the WordPress plugin repository. Previously, you had to visit his site to check for updates to the plugin. Now, that will all be handled through the respository. Widget Context enables users to specify where and when widgets are displayed using a nifty user interface. At one time, I used Widget Context on this site but I have since replaced it with something called Widget Logic. Doesn’t come with a good user interface but it gets the job done. By the way, if you enjoy Kaspars plugin, notice the donation link he put into the news post!
Even A Widgetifyr Stumps Me
A few days ago, Glenn Bennett got in touch with me to let me know about a site called Widgetifyr.com. This site is a service which aims at making the WordPress widget creation process much easier than creating the code from scratch every time.
If you’ve ever tried to turn your code into a wordpress plugin (which is how WordPress widgets get installed) you know it can get a bit tedious. Our service lets you just paste your code into a form along with some addition information and we “magically” turn it into a WordPress Plugin that allows your widget to be used in WordPress.
Immediately I thought this was a cool idea. So I took it for a test drive to see if I could create a widget using a regular WordPress function such as get_posts. As it turns out, even a widget generator can stump me.
The way this works is that you create a plugin file which you can download at the end, upload it to your plugins folder, activate it and then use the widget. So the first part of the process deals with the basic plugin stuff such as the name, version, author, etc. At the bottom of this page is the important part. This is where you name your PHP Function Name. In the text area, you’re supposed to paste your PHP code which would reside between the brackets. Here is what mine looked like.
I used this code from the example shown on the codex related to this function. Once that was done, I clicked on the create button which takes the function, wraps it with the widget code and then gives me the chance to view the code in a txt editor to copy, paste in my favorite editor and than save that file as get_posts.php. I then uploaded this file to my plugins folder. Upon activation, I was greeted with a fatal error:
Parse error: syntax error, unexpected ‘}’ in public_html/wptavern/wp-content/plugins/get_posts.php.php on line 33
Here is line 33.
I received this error anytime I tried to activate a plugin I created. I’m not sure what I did wrong but after looking through the widgetifyr help page, to get a gist as to what the widget code is supposed to look like, and it’s obvious that you need to have a little PHP experience in order to really use this tool to its fullest potential.
The more I tinkered with the site, the more I realized that Otto’s Executable PHP Widget is a much easier, speedier solution for me. With this plugin, I can create widgets without having to worry about HTML or echoing anything. Here is one example of how I use this plugin.
No copying of code, no uploading, and it just works (as long as I put the function in correctly). If you’re a coder, let me know if the service makes it easier for you to create widgets. As for myself, I’ll stick with a Otto’s solution.