[buddypress-trac] [BuddyPress Trac] #6570: Add UI for adding Profile Header Images for Users and Groups
noreply at wordpress.org
Wed Aug 26 18:24:58 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 r-a-y):
Thanks for working quickly on this, imath!
I've made some changes to the cover image template part - `02.markup-
Patch does the following:
* Moves the cover image into a separate element - `a#header-cover-image`.
This is so we can control the cover image separately outside the main
avatar and button markup. Cover photo is also clickable using the `<a>`
element (similar to Facebook).
* Fixes an issue if an admin switches to a theme with a larger width and
the cover photos were not taking up the width of the new theme. Cover
photo now uses this CSS declaration -- `background-size: cover` -- so the
image takes up the remainder of the container. I've also altered the CSS
so the cover photo looks more consistent across different themes and have
done some preliminary CSS work for our companion stylesheets. Companion
stylesheets are still a work-in-progress.
* Shows the cover photo markup even if the user has not uploaded a cover
yet. I've set the default background color to `#c5c5c5`, which matches
the Gravatar default avatar background. This is so profiles without a
cover photo will look consistent with profiles that have a cover photo.
Also, this might encourage users to set a cover photo! We could set the
cover photo link if a user is viewing their own profile so it links
directly to the "Change Cover Photo" page.
* Latest member activity update now shows in the right-hand container with
the at-mention name and buttons. Didn't really like the member update
cleared on its own line. We could even consider removing the latest
member activity update from the header entirely for our cover photo
Feedback for comment:33:
**bp_set_theme_compat_feature() vs. add_theme_support()**
A part of me would still prefer using `add_theme_support()` to declare
cover photo support, but `bp_set_theme_compat_feature()` is pretty cool
because devs can use the 'bp_parse_args' filters as in the
`swifter_xprofile_cover_image()` example above.
I'm fine with the proposed filenames for the cover photo. For avatars, I
think we should leave them alone for the time being.
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.
As BuddyBoss also has stated, I think people will want to crop their cover
photo so it displays the way they want it to.
** Admin option**
If we enable cover photos by default for every theme, I would agree with
mercime that we might need to consider an admin option. Not all site
admins love dealing with code snippets to disable something that we force
enable by default in a major release.
Btw, this is the snippet to disable profile cover image support:
`add_filter( 'bp_is_profile_cover_image_active', '__return_false' );`
Should this be `'bp_is_xprofile_cover_image_active'`?
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?
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6570#comment:35>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac