[theme-reviewers] Setting $content_width Dynamically

[Chip Bennett]

Thanks for this, Justin. This is definitely worth exploring.

On Thu, Aug 11, 2011 at 2:48 PM, Justin Tadlock <justin at justintadlock.com>wrote:

> **
> 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>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> 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>
>>> 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> 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
>>> >> 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
>>> >
>>> >
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>
>>
>
> _______________________________________________
> theme-reviewers mailing listtheme-reviewers at lists.wordpress.orghttp://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/20110810/a3edc869/attachment.htm>