[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 has-patch  |
------------------------------------+------------------

Comment (by imath):

 Replying to [comment:35 r-a-y]:
 > I've made some changes to the cover image template part - `02.markup-
 changes.patch`.

 Thanks a lot r-a-y. All your "bullet points" changes are really
 interesting and are great improvements. I have only one problem with :

 > * Shows the cover photo markup even if the user has not uploaded a cover
 yet.

 My concern is:
 I think we should let Admins decide about this. Some might want to have
 regular header if the user has no cover image and some other might want to
 "force" user to upload a cover image and i think we should let them free
 to choose. For example, they could do this to have the grey background :
 {{{
 add_filter( 'bp_displayed_user_has_cover_image', '__return_true' );
 }}}

 > **bp_set_theme_compat_feature() vs. add_theme_support()**

 I think `bp_set_theme_compat_feature()` is more in the BuddyPress
 philosophy. As @johnjamesjacoby and @modemlooper said in previous comments
 or in dev-chat: Feature should be available to any WordPress theme using
 BP Legacy. The way we add the support for the cover image in `buddypress-
 functions.php` (+ the new templates and the edited templates) is just
 making sure we play nice with BuddyPress standalone/premium themes.
 So even if i was feeling a bit like you about `add_theme_support()`, i am
 now beginning to think we're on the right way with this new function :)

 > **File renaming**
 > One really minor tidbit is for sites that are whitelisting BuddyPress.
 They might not like `wp-content/uploads/buddypress`.  It's a small thing
 that a dev can probably filter, but thought I'd bring it up.

 We can choose another name, what about 'bp-uploads' ?

 > **Cropping**
 > As BuddyBoss also has stated, I think people will want to crop their
 cover photo so it displays the way they want it to.

 Well, i really don't feel the cropping tool. It's already a pain for
 avatars as soon as we are on mobile devices, then for themes having a
 vertical nav, we don't have all the `$content_width` available, so i guess
 it can be pretty challenging to calculate ratios etc. I may be wrong about
 it so i'll check how the plugin modemlooper shared earlier in the thread
 is behaving with twentyfifteen.
 Moreover, you took the example of Facebook, Facebook (or Twitter by the
 way) does not include a cropping tool, you can eventually move the
 background but not crop it. That's probably because in mobile devices
 cropping mustn't be that great...
 I'd say i'd rather only automatically crop the width and keep all height
 and do a bit like facebook so that the user can adjust the visible part of
 his header. But this is meaning adding some js code into cover-image.js
 and new css rules ;)

 > ** Admin option**

 Well, although a part of me disagree, i don't have any strong opinion
 about adding new options, so if majority's fine with it, let's do it :)

 > I see some code to force the component from 'xprofile' to 'profile' in
 `bp_set_theme_compat_feature()`.  Is there a reason why this is done?  Is
 this because the xprofile component might not be active?

 That's because bp_is_active() is checking if the component is active using
 the option `bp_get_option( 'bp-active-components' )` And in this option we
 have like `array( 'xprofile' => 1 )`. So `xprofile` is used. But when the
 xProfile component is created it's using `buddypress()->profile = new
 BP_XProfile_Component()` in its loader. So the feature is attached to
 buddypress()->'''profile'''

 So 6570.03.patch is including all improvements r-a-y suggested in his
 patch except for the part that was "showing the cover photo markup even if
 the user has not uploaded a cover yet"

 Then i have a new concern, considering 2.4 dev-cycle and the time we have
 till beta. Should we focus on the user's cover image and work on the
 group's one in next release ?

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