The Shiba Widgets plugin allows you to assign different widgets to different posts, pages, categories, or tags.
[Full Shiba Widgets description.]
New features for Shiba Widgets 1.3 –
1. Custom Post Types
Widget sets are now represented as custom post types. This makes the back-end cleaner, and enhances usability. There is now a Widget Set tab on the dashboard that allows you to manage your widget sets. Below is the new Edit Widget Set interface.
Click on the View Widget Set button to preview the look of your widgets on a blog page.
Custom post types also allow for more natural tracking of widget set information. For example, the categories and tags associated with a widget set are now shown. Clicking on the tags and categories will show all related posts.
Shiba Widgets 1.3 will only operate on WordPress 3.0 and above. If you are using WordPress 2.9 then please download Shiba Widgets 1.2.
When the plugin is activated, it will try to convert all of your previous widget sets from taxonomy objects into custom post types. However, it will not delete your old taxonomy objects.
If you encounter any bugs, your old data should still be accessible if you revert back to an older version of the plugin.
2. Default Widget Set
When you first install the plugin, it will automatically create a default widget set if one does not already exist. The Default widget set has post_title = ‘Default’.
The plugin will create the default widget set based on your current widget configuration. When the plugin is deactivated, it will restore the Default widget set as your regular WordPress sidebars.
The Default widget set is used in cases where a widget set has not been previously assigned.
3. Widget Set Options
Widget sets may now be to assigned to archive pages. Many thanks to James for his great input on this.
You can also hook into the plugin and specify your own widget set conditions by using the pre_shiba_get_widget filter.
add_filter('pre_shiba_get_widget', 'gallery_get_widget', 10, 2);
function gallery_get_widget($widget, $post) {
if ($post->post_type == 'gallery')
return 1234; // Return relevant widget set id
else
return 0;
}
Please Use a Test Site
It is safest to first install a plugin on a test site before using it on your production site. This is a big update because it involves converting old taxonomy based widget sets into custom post types.
Using a test site first is highly recommended.
Greetings Shibashake,
I just upgraded to WordPress 3.1 and attempted to edit/manage an existing widget on my site, but received the following error:
Call to undefined function tag_rows() in /wp-content/plugins/shiba-widgets/shiba-edit-widgets.php on line 212
The rest of the plug in appears to be working ok…just can’t make those changes to the saved widget sets with this error happening and am working towards meeting today’s deadline. Fortunately the issue is on staging only which also doubles as my dev environment. Production is still on 3.0.5, but I’d hate to be doing live edits there (defeats the purpose of staging/prod).
I assume something changed in the core that needs to be addressed. Please help.
Thank you,
~D
Thanks for reporting this. I am working on testing and fixing the latest 3.1 updates.
Please let me know if you find more bugs.
Ok I just tested Shiba Widgets and it seems to work fine on Release 3.1.
Likely, you are using an old version of the plugin. Try uploading the latest zip and let me know how it goes.
Hi, this looks like a great plugin…where do I download 1.3.1? Did I miss the download link somewhere? I downloaded and installed 1.2.2 and it isn’t quite working properly in wordpress 3.0.1. Thanks 🙂
The download link at the end of this page should load the latest version. Or else, here is the link –
http://shibashake.com/wordpress-theme/shiba-widgets.zip
Let me know if you run into any problems.
This plugin has caused so much wasted time. I installed it on several 3.0 wordpress site and every time I make a widget in the widget set it shows on every page no matter what I select on the edit post or edit page drop down.
In other words it acts like I have not even installed it.
I would never recomend this fucking headache to any one!!!
Make it work right BEFORE you put this shit out there for people to waste there time on!!!!
There may be much more that ails you than a simple plugin. I hope you find what you are looking for.
I hope you won’t let that person’s comments in anger throw you off even if there are bugs (if any with any plugin …generally speaking), it’s always work in progress. Overall, your plugin here is a very good start for grouping widgets like Movable Type offers, so keep at it and don’t give up on this one. Cheers!
Thanks sj. Comments like yours help a lot. 😀
a) How do I upgrade from 1.2.2 to 1.3 without losing my current widget setup?
b) If there was a way to export the widget sets, I’m sure everyone would love it! That way, people wouldn’t have to worry about losing their widget setup on accident.
c) I’m running into a weird issue where updating one widget instance propagates to all the other widget sets. I have a widget that is in the same spot on all the different sets, but needs to have different settings.
The plugin will automatically convert your old widget sets into new custom post type objects. It will not delete your old widget sets, so if there are bugs, you can always revert back.
You can already export the widget sets because they are taxonomy objects in version 1.2 and custom post types in version 1.3. However, the individual widget settings are not exported by WordPress. As a result, to move widget sets across blogs, we currently need to transfer the individual widget settings manually.
Is this with text widgets? If so, it is fixed in the new version, or you can upload the latest 1.2 patch, where the propagate bug has also been fixed.
http://shibashake.com/wordpress-theme/Download/shiba-widgets-1.2.zip
I know, that’s my point. I have a good 10 different widget sets that all have different custom made widgets with their own settings. It takes me a good hour to set everything up. If I could just export the settings from my development site, and import them to the live site without having to adjust all the settings, that would be awesome!
No, I’m using custom written widgets.
Also, I just upgraded from 1.2 to 1.3 on my test site and it deleted most, if not all of my widgets. It’s seemingly sporatic, which widgets got deleted.
So the widget sets transferred over properly but there are missing widgets within each set?
What does the widget count say? Does it count the widgets that have disappeared?
My guess is that there are problems with the custom widgets because not all of them are standard and the plugin relies on certain standard entries and hooks in the individual widget arrays. For example, when a widget set is copied, some custom widgets may not get duplicated because it is not structured in the standard way.
If you give me more details such as which individual widgets got deleted, which got copied, etc., then I can try and duplicate the issue on my setup.
Yeah that would be really nice to have. The problem is that widget settings are stored as WordPress options, and different custom widgets use their own option name. Unless there is some kind of standard, it is impossible to track and copy all of the widget settings.
It is possible to copy all of the current standard widget settings and maybe save them into taxonomy objects so that they naturally get exported and imported. But then, when you try to integrate the old widget settings together with existing widget settings there could be conflicts in the widget-ids.
It can be done, but it will likely be very complicated, time consuming, and somewhat messy. This is mainly due to how WP currently stores individual widget settings as a serialized array in wp_options rather than as separate objects.
Hmmm… I see how that could get complicated… Being that most all of the widgets I use are custom built, maybe I could edit all of those to save the settings somewhere else… perhaps in the update() function…
Here’s another idea, is there a hook for when widgets get saved?
Also, it seems that things are being saved in multiple ways. There’s the widget save button on the specific widgets. Does that only save the settings for that widget? Then there is when you are adding/removing/moving a widget within a sidebar, the rotating circle thing comes up letting you know that something is being saved. Then there is the actual update widget set button. It seems like that button would be redundant. What was the reason for adding that? Could the fact that things are being saved in multiple ways be the reason widgets are getting deleted and saving to the wrong sets, etc?
Let me know if there’s any particular thing I could start testing on. This is a great plugin, but it just doesn’t feel reliable enough for me to feel comfortable using it on a live site. Do you have a list of bugs/potential bugs that you are working on?
Yes that saves the settings for that widget alone.
That saves the current widget state into your widget set. Having the button allows you to manipulate the widgets until you are happy with them before saving them into a widget set. Saving into a widget set is a larger operation involving more tests and a larger database write (like saving a post), therefore it may not be very efficient to do this too often.
Yeah you are absolutely right. There could probably be a cleaner interface if I rewrote the entire Widget Editing system from scratch, but there are many advantages to using the native WP Widget Editing interface.
If you can give me a description of one of your widget sets that did not transfer properly – including all widgets contained, what did transfer, what did not transfer, and the custom plugins it relies on, I can look into the matter in greater detail.
Have you looked at Widget Logic? I have heard good things about it, and it may better suit your needs. It is on the wordpress.org plugins directory.
P.S. Can you send me an email, so I have your email address? I want to email you the file that has all of my custom widgets in it so that you can check it out.
I’m using a completely custom built theme, with custom built widgets. If you want, I could email you the plugin file that has all of the widgets in it. I haven’t developed many widgets in the past, so maybe there is some sort of compatibility issue…
Also, I noticed somewhere where you mentioned not having multiple sets open at the same time… what does that do? That may have been the issue. I had all the sets open in a tab at the same time.
I’ll try your test and let you know how it works.
Currently, there is only one global database variable that is used to store the interim widget set results. This is because I am using the native WordPress interface to assign widgets to sidebars.
If there are multiple edit screens open at the same time, only the last widget state will be tracked. So when you do a save in any of the screens, only the last widget state will be saved into the widget set – over-riding your previous widgets.
Ahhhhh…. everything makes sense now. I am positive that is what happened. I’ll definitely do more testing and see if I can break the plugin, and I’ll let you know if I find any other holes. Thanks a million! Great plugin, btw!
I am using your plugin, and when I save the widget sets, it sporadically removes widgets from the site. For instance, I placed 4 widgets in the footer sidebar, clicked Update, and now there are only 3 widgets in the footer. Any help would be appreciated!
Hello Michael,
– What theme are you using?
– What plugins are you using?
– What specific widgets are you adding?
– Is there a test HTML page I can look at?
The more detail you can give me, the better, so that I can try and duplicate the issue on my test site.
It would also be helpful if you could try the following test –
First I would start by just creating a widget set with 4 standard WP widgets (e.g. just 4 archive widgets). Save the widget set. Does it save properly?
Then add another archive widget, does it save properly?
If it works, try expanding from there and adding non-standard widgets. This will tell me exactly what widget class is causing the problem.
Let me know what results you get. Thanks.