[theme-reviewers] Setting $content_width Dynamically
Justin Tadlock
justin at justintadlock.com
Thu Aug 11 19:48:35 UTC 2011
Here's what I do for dynamic layouts on the front end. I don't use
$content_width for this. I filter 'embed_defaults' to handle embeds
because this is where the problems arise. For images or anything else,
you can use CSS.
The basic functionality would be something like:
=======
add_filter( 'embed_defaults', 'my_embed_defaults' );
function my_embed_defaults( $args ) {
$layout = my_get_layout_function();
if ( '1-column' == $layout )
$args['width'] = 900;
elseif ( '2-columns' == $layout )
$args['width'] = 600;
return $args;
}
======
On 8/10/2011 2:25 PM, Chip Bennett wrote:
> Okay, one more stab at this.
>
> First, I'm hooking oenology_set_content_width() into two hooks, one on
> the front end, and one on the back end:
>
> add_action( 'wp_head', 'oenology_set_content_width' );
> add_action( 'admin_init', 'oenology_set_content_width' );
>
>
> Second, I changed oenology_get_current_page_layout() to accommodate
> both contexts:
>
> function oenology_get_current_page_layout() {
> global $post, $oenology_options;
> $custom = ( get_post_custom( $post->ID ) ? get_post_custom(
> $post->ID ) : false );
> $custom_layout = ( isset( $custom['_oenology_layout'][0] ) ?
> $custom['_oenology_layout'][0] : 'default' );
> $layout = '';
> if ( ! is_admin() ) {
> if ( is_page() ) {
> if ( 'default' == $custom_layout ) {
> $layout .= $oenology_options['default_static_page_layout'];
> } else {
> $layout .= $custom_layout;
> }
> } else if ( is_single() ) {
> if ( 'default' == $custom_layout ) {
> $layout .= $oenology_options['default_single_post_layout'];
> } else {
> $layout .= $custom_layout;
> }
> } else if ( is_home() || is_archive() || is_search() || is_404() ) {
> $layout .= $oenology_options['post_index_layout'];
> }
> } else if ( is_admin() ) {
> if ( 'page' == $post->post_type ) {
> if ( 'default' == $custom_layout ) {
> $layout .= $oenology_options['default_static_page_layout'];
> } else {
> $layout .= $custom_layout;
> }
> } else if ( is_single() ) {
> if ( 'post' == $post->post_type ) {
> $layout .= $oenology_options['default_single_post_layout'];
> } else {
> $layout .= $custom_layout;
> }
> }
> }
> return $layout;
> }
>
>
> I *think* this covers all bases?
>
> I would love to hear anyone's thoughts on best practices here!
>
> Chip
>
> On Wed, Aug 10, 2011 at 1:55 PM, Chip Bennett <chip at chipbennett.net
> <mailto:chip at chipbennett.net>> wrote:
>
> It definitely impacts large images and oembeds on the front end.
> So, setting it *only* in the Admin side wouldn't help with those.
>
> Question: what if there was one *global* set (e.g. using the
> largest width), and then a front-end override (e.g. using my
> original function)? There's nothing preventing that, is there? Let
> me play around with it a bit. I want to figure out what is the
> best-practice implementation, while allowing for dynamic content
> width (primarily for display of large-size images, and embedded
> videos.
>
> Chip
>
> On Wed, Aug 10, 2011 at 1:46 PM, Otto <otto at ottodestruct.com
> <mailto:otto at ottodestruct.com>> wrote:
>
> Consistency is something that happens to other people.
>
> The $content_width is actually used for a lot of things. It also
> controls the width of the fullscreen editor, for example. It also
> controls the width used for oembed requests. It controls the
> maximum
> value of the "large" image size when displayed in the editor.
>
> So it definitely needs to be set globally. In fact, it
> probably only
> needs to be set in the admin side, I don't think it has much
> if any
> effect on the public facing side of the site. Although I'm not
> sure
> about that, especially for the oembeds case.
>
> -Otto
>
>
>
> On Wed, Aug 10, 2011 at 1:35 PM, Chip Bennett
> <chip at chipbennett.net <mailto:chip at chipbennett.net>> wrote:
> > So what would be best practice here? Perhaps setting it
> separately for
> > is_admin(), and using the largest $content_width value?
> Perhaps hooking it
> > into admin_init?
> > Also: why is $content_width used on *insertion*, yet
> controlled by the
> > *Theme*? That isn't intuitive. And, wouldn't it potentially
> introduce issues
> > whenever the Theme is changed *after* insertion?
> > Chip
> >
> > On Wed, Aug 10, 2011 at 10:22 AM, Otto
> <otto at ottodestruct.com <mailto:otto at ottodestruct.com>> wrote:
> >>
> >> I've tried this sort of thing, and it is *fraught* with peril.
> >>
> >> Make sure you test inserting content into various posts and
> pages and
> >> such thoroughly. The content width is used on content
> insertion, not
> >> just on content display.
> >>
> >> Basically, the media uploader expects the content width to
> be set when
> >> images are uploaded and resized. If you're only setting it
> on wp_head,
> >> your results may be unexpected for various size values in
> the media
> >> section.
> >>
> >> -Otto
> >> _______________________________________________
> >> theme-reviewers mailing list
> >> theme-reviewers at lists.wordpress.org
> <mailto:theme-reviewers at lists.wordpress.org>
> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> <mailto:theme-reviewers at lists.wordpress.org>
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
> >
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> <mailto:theme-reviewers at lists.wordpress.org>
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110811/cd5e144b/attachment-0001.htm>
More information about the theme-reviewers
mailing list