[theme-reviewers] Setting $content_width Dynamically

[Chip Bennett]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110810/2800442c/attachment.htm>