[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