I wasn’t sure if i would answer or simply vote to close this topic, i feel i sufficiently asnwered the original topic you’re referring to, i’d only be repeating myself here. That said, here’s an upto date version you can use(only took me 2 mins), you only need implement your own code to truncate the … Read more
I coded my own answer together using a filter and dynamic_sidebar_params: <?php add_filter(‘dynamic_sidebar_params’,’io_blogroll_class’); function io_blogroll_class($params){ $params[0][‘before_widget’] = ‘<li class=”‘.$params[0][‘widget_name’].’ box”>’; $params[0][‘after_widget’] = ‘</li><!–‘.$params[0][‘widget_name’].’–>’; if ($params[0][‘widget_name’] == “Links”){ $params[0][‘before_widget’] = ‘<li class=”‘.$params[0][‘widget_name’].'”>’; $params[0][‘after_widget’] = ‘</li><!–‘.$params[0][‘widget_name’].’–>’; } return $params; } ?> The first lines actually override whatever you programmed register_sidebar() or register_sidebars()to put before and after a … Read more
The after_title does not go through any transformations. In fact only the before_widget does: http://core.trac.wordpress.org/browser/tags/3.3.1/wp-includes/widgets.php#L876 However, a little lower you can see that $params = apply_filters( ‘dynamic_sidebar_params’, $params ); there’s a filter you can hook to do your own filtering. add_filter( ‘dynamic_sidebar_params’, ‘wpse_45418_change_after_title’ ); function wpse_45418_change_after_title( $params ) { $id = $params[0][‘widget_id’]; if ( $id … Read more
Widget are not part of hierarchical parent/child theme relation, so you would need to follow more generic development process: Optionally disable widget registration in parent theme (if possible to do cleanly – with hooks or otherwise). Extend (as in widget’s PHP class) or fork (copy and modify the code) widget in child theme. Register your … Read more
All of these scripts are already registered to print in the footer. See wp-includes/script-loader.php for details. When you try to register the scripts again WordPress doesn’t change that. The workaround would be to register a new script for wp_head with those scripts as dependencies (the third parameter of wp_enqueue_script()). Do not register the scripts in … Read more
If you’re comfortable changing the code where the widget is outputted you could use the is_user_logged_in() function. Something like this: <div id=”widget_area”> <?php if ( is_user_logged_in() ) { // show nothing } else { dynamic_sidebar(‘widget_name’); } ?> </div> The downside being that this is now hard coded and you might have to add this function … Read more
dynamic_sidebar_params is the filter that lets you modify those parameters on a per-widget basis. It fires for every sidebar though, so you’ll need to use both add_action & remove_action call. Try var_dump once before writing the code to get an idea of what you have to do ADDED AN EXAMPLE ON REQUEST This example adds … Read more
You are not passing your description correctly. Really, you aren’t passing it at all. public function __construct() { parent::WP_Widget(false, $name=”Kevins Textbox”); array(‘description’ => __(‘A text widget created by Kevin Ullyott for practice in creating widgets’) ); } That ‘description’ line is creating an array but you aren’t doing anything with it. It is just floating … Read more
Ok, so, for some reason I can’t comprehend, the answer is that the div element containing the tabs should have a class and not an id for jQuery UI to work properly, as such: <div class=”mytabs”> and jQuery(document).ready(function($) { $(“.mytabs”).tabs(); }); Just for the record, the way I enqued the scripts is: add_action( ‘admin_enqueue_scripts’, ‘load_my_admin_js’ … Read more
In the register_sidebar() call in functions.php. Look for before_widget and after_widget and modify as appropriate. The code below is the default usage. ‘before_widget’ => ‘<li id=”%1$s” class=”widget %2$s”>’, ‘after_widget’ => ‘</li>’,