[buddypress-trac] [BuddyPress Trac] #6570: Add UI for adding Profile Header Images for Users and Groups
noreply at wordpress.org
Thu Aug 27 13:05:39 UTC 2015
#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-
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
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' ?
> 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
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/>
More information about the buddypress-trac