WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 20 months ago

#10976 reopened enhancement

Add before_content and after_content to widget options

Reported by: newkind Owned by: azaozz
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Widgets Keywords: needs-refresh 2nd-opinion
Focuses: Cc:

Description

Hi,

I'd like to request adding a two new parameters to the widget array for easier customization when creating themes.

Parameters are : before_content and after_content (naming can be different)

Basicaly we have now before_widget, after_widget, before_title and after_title and it's working great, but if while creating a theme you'd like to add more complexity to the graphics surrounding widget you have to add more divs etc. to make it work and look great, and if you got some divs or anything else between title and content you got a problem. Sure you can put the code in the after_title and it will work, but what in case if someone will decide to leave the title empty ? Your widget lacks code and your theme messes up.

Please consider it! :)

Attachments (3)

widget-content.png (18.5 KB) - added by greenshady 8 years ago.
10976.widget-content.diff (11.2 KB) - added by lancewillett 7 years ago.
Patch to add before_content and after_content to default widgets
modified.10976.patch (12.0 KB) - added by lavoiesl 6 years ago.
This is a revised version of http://core.trac.wordpress.org/attachment/ticket/10976/10976.widget-content.diff because is it not compatible with current WP version anymore

Download all attachments as: .zip

Change History (25)

#1 @scribu
8 years ago

  • Keywords 2nd-opinion added; widget array content code parameter add removed
  • Priority changed from high to normal

#2 @scribu
8 years ago

  • Summary changed from More widget parameters to aaray to Add $before_content and $after_content to widget options

#3 follow-up: @azaozz
8 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

It seems this can be added in the widget method for a simple widget. However adding it globally would not make sense for more complex widgets that output several different elements and don't have distinct title and content.

#4 follow-up: @greenshady
8 years ago

I need a better explanation for why we should close this than the complexity of a widget. I've yet to see a widget that would not benefit from this addition (though I'm sure there are some edge cases).

One of the most-requested features I get for widgets with my themes and plugins that add widgets (from both users and designers) is an easy way to apply specific styles to the widget content. Instead of saying, "Oh yeah, just apply your styles to the .widget-content class," I have to tell them they must hack their CSS files to death to get something so simple working.

#5 in reply to: ↑ 4 @filosofo
8 years ago

Replying to greenshady:

I need a better explanation for why we should close this than the complexity of a widget. I've yet to see a widget that would not benefit from this addition (though I'm sure there are some edge cases).

One of the most-requested features I get for widgets with my themes and plugins that add widgets (from both users and designers) is an easy way to apply specific styles to the widget content. Instead of saying, "Oh yeah, just apply your styles to the .widget-content class," I have to tell them they must hack their CSS files to death to get something so simple working.

Could you provide a specific example of something that either can't be done or is unnecessarily difficult under the status quo? That would probably help bolster your case.

#6 @greenshady
8 years ago

I just added a simple example of how this could be useful. If a more complex design is needed, I'm sure I could whip one up.

What's shown in the attached image is a widget title that should not have any left or right margin and widget content that needs to have left and right margin.

This is basically the equivalent of the <div class="entry"> (default theme) that wraps the post content.

#7 @gordonbrander
7 years ago

I also thing this is would be a very helpful feature. It's a very common markup pattern for everything from articles to callout modules.

In addition to the example use-case greenshady gave, here are some others:

From a semantic standpoint I think it's valuable to be able to define the content area of a widget as a unique entity. This is a logical markup structure found in microformats like hAtom (.entry-content), hProduct (.description), as well as a common ad-hoc pattern. Check out the comments on ma.tt for example (.comment-body), or the articles in the new HTML5 Toolbox theme. As widget areas are used in more areas than just sidebars (reorder-able home pages for example), this will become even more useful. I may, for example, want to create a reorder-able magazine home page syndicated with the hAtom microformat.

From a practical standpoint it allows you to create more flexible design systems for sites. For example, you may have a widget with padding and a background color. That widget may contain content wrapped in a paragraph, or just a naked string of text (you never know with clients). If there is a naked string of text, your pretty bottom spacing is gone. But, if you have a content wrapper, you can put a bottom margin on the content equal to the margin of the potential paragraph tag. Boom: margin collapse takes care of the rest, keeping your spacing consistent and your design bulletproof.

#8 @gordonbrander
7 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Apologies, should have re-opened with last comments.

#9 in reply to: ↑ 3 @lancewillett
7 years ago

  • Cc lance@… added

Replying to azaozz:

It seems this can be added in the widget method for a simple widget. However adding it globally would not make sense for more complex widgets that output several different elements and don't have distinct title and content.

Yes, this would only be for simple widgets. More complex widgets can generally be styled without a problem based on more complex the HTML output.

Though many widgets do not need an extra wrapper element, some do. In those cases it would be helpful to have widget content before/after hooks available, but empty by default.

Case in point: if you look at the default widgets in /wp-includes/default-widgets.php you'll see that at least two of the default widgets use an extra wrapper element around the widget content (calendar and tag cloud).

The main benefits I see for adding in the hooks are:

  1. The ability to style only the widget content area (avoiding styling the title and overall widget wrapper).
  2. The ability to specifically target elements inside the widget content area.

This happens often in themes where the widget has multiple block level elements, like a text widget with multiple paragraph elements. The last paragraph element in the widget content might have bottom margin, for example, and if you cannot target only the paragraph elements in the widget content area it's difficult to remove the bottom margin to ensure that the widgets themselves have consistent spacing.

It is possible to target the last element with a last:child selector, but that isn't supported in older browsers, so having an HTML element is the only way to achieve this until all browsers support CSS3.

As mentioned in the original ticket, the way themes address this now is to add in an extra div in the "after_title" hook and then close it with the "before_widget" -- the problem is that if the title is empty you end up with an improperly formed div element.

@lancewillett
7 years ago

Patch to add before_content and after_content to default widgets

#10 @lancewillett
7 years ago

  • Keywords has-patch needs-testing added
  • Summary changed from Add $before_content and $after_content to widget options to Add before_content and after_content to widget options

#11 follow-ups: @nacin
7 years ago

This came up over the wp-hackers list not long ago. My solution was indeed to use after_title and after_widget, but to prevent the improperly formed div if the title was empty, to also use before_widget and before_title:

before_widget - <div class="widget-notitle-content-container">
before_title - </div><h4>
after_title - </h4><div class="widget-content-container">
after_widget - </div>

http://lists.automattic.com/pipermail/wp-hackers/2010-June/032648.html. The rest of the thread surrounds that post.

#12 in reply to: ↑ 11 @lancewillett
7 years ago

Replying to nacin:

This came up over the wp-hackers list not long ago. My solution was indeed to use after_title and after_widget, but to prevent the improperly formed div if the title was empty, to also use before_widget and before_title

That might help solve the title-less widget issue, but doesn't speak to the goal of the ticket: to add a wrapper element around just the widget content.

#13 in reply to: ↑ 11 @gordonbrander
7 years ago

  • Cc gordonbrander added

Replying to nacin:

This came up over the wp-hackers list not long ago. My solution was indeed to use after_title and after_widget, but to prevent the improperly formed div if the title was empty, to also use before_widget and before_title:

That's definitely a pragmatic solution. Yet, having a bunch of empty divs in the markup is definitely a front-end hack. It would be much better to solve this problem instead of working around it.

#14 @suhanto
7 years ago

Oh at last I see an effort to incorporate before_content and after_content parameters to the widget. I was looking for this features many weeks ago, I've googled, I've look into the source codes, with no luck.

I think this is good idea, these two parameters definitely will make us easier when designing a theme.

I'm now in the process of porting a Joomla theme to WordPress theme and stuck with this problem. Since the Joomla theme has 'content wrapper' div, but I couldn't find a way to 'inject' this wrapper element in WordPress widget.

So, will this be approved to core? If yes, when will it be part of the release?

#15 @nacin
7 years ago

  • Milestone changed from 2.9 to Future Release

#16 @newkind
6 years ago

  • Cc newkind added
  • Keywords changed from 2nd-opinion, has-patch, needs-testing to 2nd-opinion has-patch, needs-testing

#17 @eddiemoya
6 years ago

  • Keywords changed from 2nd-opinion has-patch, needs-testing to 2nd-opinion has-patch needs-testing

I am not sure if perhaps I am misunderstanding, but can not any theme add custom variables when registering a sidebar?

I'll borrow an example from the codex page and modify it:

/* In theme functions.php */
    register_sidebar(array(
	'name'          => sprintf(__('Sidebar %d'), $i ),
	'id'            => 'sidebar-$i',
	'description'   => '',
	'before_widget' => '<li id="%1$s" class="widget %2$s">',
	'after_widget'  => '</li>',
	'before_title'  => '<h2 class="widgettitle">',
	'after_title'   => '</h2>' );
        'custom_var' => 'something custom' //My custom variable
    ));

Then that variable will immediately be available for use within the widget() method of WP_Widget. I'll once again borrow from a codex example and modify it.

/* In your widget */

	function widget( $args, $instance ) {
		extract( $args );
		$title = apply_filters( 'widget_title', $instance['title'] );
		echo $before_widget;
		if ( $title )
			echo $before_title . $title . $after_title; ?>
		Hello, World!
		<?php echo $after_widget;

                /** Using our custom variable **/
                if ( $custom_var ) {
                    // Use this if the theme has given a value for our custom variable
                    echo $custom_var;
                } else {
                    // Some default value to use if the theme has not supplied one
                    echo 'default stuff'; 
                }
	}

I kept it very simple in that example, and clearly there are better ways to setup default values, especially if you have more of these custom variables.

The only reason I could see an absolute imperative to bake in new specific variables is because we want to encourage developers of publicly available themes to define the new variables and style them accordingly, and that might be a valid point. However if the primary concern is one of *how* to create additional variables at all, and if you are the theme and widget developer - doing this is already possible. If intended for public consumption, a widget developer can always suggest theme developers use the custom variables and set defaults for the many cases for which they wont.

@lavoiesl
6 years ago

This is a revised version of http://core.trac.wordpress.org/attachment/ticket/10976/10976.widget-content.diff because is it not compatible with current WP version anymore

#18 @bainternet
6 years ago

  • Cc admin@… added

#19 @chrisvanpatten
5 years ago

  • Cc chris@… added

#20 @alex-ye
5 years ago

  • Cc nashwan.doaqan@… added

#21 @valendesigns
3 years ago

  • Keywords needs-refresh added; 2nd-opinion has-patch needs-testing removed

@azaozz I'd like to pick up this ticket for 4.3 if you don't mind.

#22 @Mte90
20 months ago

  • Keywords 2nd-opinion added

I've tried to update that patch but i see in the code that after_widget is used like the after_content and the same also for the before_*.

I think that ticket can be obsolete.

Note: See TracTickets for help on using tickets.