[buddypress-trac] [BuddyPress Trac] #6570: Add UI for adding Profile Header Images for Users and Groups

[buddypress-trac]

#6570: Add UI for adding Profile Header Images for Users and Groups
--------------------------+------------------
 Reporter:  mercime       |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  2.4
Component:  API           |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------

Comment (by imath):

 I'm sorry, this is going to be a long comment :(

 First i now understand better r-a-y's advice about the fact we should only
 provide support for "twenties" theme. I think he's absolutely right.
 Second, it's definitely a theme feature, so i really think we should rely
 on the WordPress "theme_support" API.
 Third, thanks for your feedback @BuddyBoss, it made me realize that if the
 theme add supports for the cover image then when checking if the current
 theme supports the feature within a plugin or the theme, it will return
 true even if BuddyPress is deactivated, so if you need to include file
 that are using BuddyPress functions or classes, i guess we need to find an
 easy way to try to avoid any trouble.

 So in 6570.first-step.patch, i've taken in account these three points. And
 here's what's inside this first step:

 Here's an example of how a theme could set the support for BuddyPress
 cover images :

 {{{
 add_theme_support( 'buddypress-cover-images', array(
         'width'        => $width,
         'height'       => $height,
         'callback'     => 'theme_prefix_cover_images_callback',
 ) );
 }}}

 Imho, as it will be very difficult for BuddyPress to be sure of how the
 item-header is for any theme, i strongly advise the theme to define the
 callback parameter. This callback will then return an inline css we will
 be able to output.

 Then i thought this may be enough in most cases, but maybe not in some
 cases. So i think we should also be able to have different parameters
 according to the single item. So far we have Members and Groups single
 items, and in a near future the Blogs one and who knows plugins can also
 add their specific single items..

 So i think we should extend this by component. In the patch
 `bp_set_theme_support()` is doing this job. If the theme support is like
 the above, each single items header will use these parameters, but a theme
 might want to use different dimensions/callback according to the
 component. So it can achieve this by using :

 {{{
 add_theme_support( 'buddypress-cover-images', array(
         /* buddypress()->members->id */
         'members' => array(
                 'width'        => $width_members,
                 'height'       => $height_members,
                 'callback'     =>
 'theme_prefix_members_cover_images_callback',
         ),
         /* buddypress()->groups->id */
         'groups' => array(
                 'width'        => $width_groups,
                 'height'       => $height_groups,
                 'callback'     =>
 'theme_prefix_groups_cover_images_callback',
         ),
 ) );
 }}}

 Or the theme can also choose to support only one component, for example to
 only add support to members cover images, he can do this :

 {{{
 add_theme_support( 'buddypress-cover-images', array(
         /* buddypress()->members->id */
         'members' => array(
                 'width'        => $width_members,
                 'height'       => $height_members,
                 'callback'     =>
 'theme_prefix_members_cover_images_callback',
         ),
 ) );
 }}}

 I've also made available a 'default_cover' parameter if the theme wants to
 provide a "mystery cover". I think BuddyPress just need to display the
 item-header like it is today if the user/group has no cover image.

 If the theme's need to be sure BuddyPress is ready to bring the support,
 he can use this check :
 {{{
         if ( ! current_theme_supports( 'buddypress-cover-images',
 'inactive' ) ) {
                 require( 'file' );
         }
 }}}

 By default without BuddyPress activated, `current_theme_supports(
 'feature', 'parameter' )` will always be true if the theme added support
 for the feature. `bp_set_theme_support()` will set inactive as false,
 meaning BuddyPress can bring the support. Of course the theme could also
 use something like:

 {{{
 if ( function_exists( 'buddypress' ) && bp_is_active( 'members' ) ) {
         require( 'file' );
 }
 }}}

 But i thought it was less pretty :)

 About the twenties. `BP_Legacy->setup_supports()` is there to bring the
 BuddyPress cover images feature by default (unless the twenty theme
 already added this support, eg: a child theme could do this). I've
 realized that since the introduction of the companion stylesheets that for
 each concerned themes we cannot rely anymore on the `$content_width`
 global. So i've used width my browser calculated for the themes having a
 companion stylesheet, i guess it needs to be checked..

 ==== Now how the cover image should look like ? ====

 First i've tested @modemlooper's plugin. And unless i did something wrong,
 once i've uploaded a valid cover image, nothing was displayed into my
 profile header. After a deeper look, i guess i may miss a css rule in my
 theme, because the plugin is adding a new div above the item-header and
 uses the uploaded cover photo as a background. The problem is my div has
 no height, and the cover photo is not displayed. I've added a height of
 around 300px and it showed over the item-header. Imho, i think we
 shouldn't add an extra div but directly use the existing `#item-header` a
 bit like what's doing the Boss theme by @BuddyBoss. But then, we have a
 probleme! We do have a lot of text in this div, and once i've tested
 without too much css manipulation, this is what i got on twentyfifteen:

 [[Image(https://cldup.com/63b1pCJ-YK.png)]]

 It's pretty difficult to read the text!

 I like what's doing the Boss theme, well Facebook & Twitter are kind of
 doing similar things, they use a white color with a text shadow. But
 applying this trick on each text of this div without touching the action
 buttons is a bit annoying and we hardly enjoy the cover image as she's
 full of text. So the best way of displaying it seems to be this one imho:

 In twentyfifteen :
 [[Image(https://cldup.com/qS4B55TF2J.png)]]

 In twentyfourteen :
 [[Image(https://cldup.com/53xTcahO-N.png)]]

 In twentythirteen :
 [[Image(https://cldup.com/vY-LihPG0g.png)]]

 In twentytwelve :
 [[Image(https://cldup.com/Y9IJtdm-tU.png)]]

 Even if twentytwelve fails (because unlike the others the item-header-
 content has no width) It's interesting to see that the white on white is
 still readable :)

 The next problem is smaller screen. If we're ok with the layout i'm
 suggesting, i think we should have this kind of layout on smaller screens
 :
 [[Image(https://cldup.com/5AMJE8mLkh.png)]]

 As you can see this is not an easy part, and i'm not the best in web
 design! So it would be awesome if @hnla @mercime @BuddyBoss and every "web
 design star" could find the best solution on how to display this cover
 photo. If you need to run some tests, you just need to apply the patch and
 switch themes. The css part to edit is in `src/bp-templates/bp-legacy
 /buddypress-functions.php` inside the `bp_legacy_theme_cover_image()`
 function. PS: i haven't done anything for the groups cover images as you
 will see.

 ==== Uploads / BP Attachments API ====

 I'm now going to explore this part of the patch, but before going too fast
 and furious about it, i'd like to have your feedback about my first ideas:
 - the UI to set the cover image should be similar to the Avatar one
 (extendable tabbed interface: Upload|delete at the begining)
 - It's time we think about what's the best file organization. as i've said
 in this [https://buddypress.trac.wordpress.org/ticket/6570#comment:8
 comment]. My personal preference would be
 `uploads/buddypress/component_id/component_single_item_id/subfolders`
 where subfolders could be 'avatar', 'cover-image', 'year/month' (< like
 WordPress Year than a subfolder for each month). For the members component
 it would be `uploads/buddypress/members/1/cover-image`. Problem is:
 `rename( 'uploads/avatars/1', 'uploads/buddypress/members/1/avatar' )`. Of
 course we can use `/uploads/cover-images`, `/uploads/group-cover-images`
 etc.. But it seems less "tidied" to me, and i think having a 'buddypress'
 root folder makes it easier to understand for users..
 - It may be the time to "init" what could be the structure of a future
 required component using a specific custom post type to organize the files
 and extending the WordPress Attachments API according to our specific
 needs.
 - We would then be able to have a very generic upload UI and eventually
 add a new browse 'tab' to the avatar's one and the future cover images's
 one so that users could be able to choose an already uploaded image as an
 avatar or a cover photo, or so that it would be easier to include an
 'Upload|Browse' UI inside the activity post form...

 Or we could reproduce how we're doing with avatars..

 What do you think/prefer ?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6570#comment:19>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac