Skip to:

Opened 12 years ago

Closed 11 years ago

Last modified 7 years ago

#3606 closed defect (bug) (fixed)

BuddyPress default isn't responding to devices size wise

Reported by: karmatosed's profile karmatosed Owned by: karmatosed's profile karmatosed
Milestone: 1.6 Priority: normal
Severity: major Version: 1.5
Component: Templates Keywords: has-patch needs-testing


As the theme is responsive we should reflect this in the viewpoint meta to make it truly fit the device it's being viewed on.

I suggest we add a viewpoint meta for instance:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Coupled with this we'd also be looking to add an image % such as:

img { max-width: 100%; }

These are 2 fairly simple fixes we can do to make the theme far more responsive.

The only downside to turning on viewpoint is it should only trigger in theory if the user has responsive 'on'. Perhaps as it's a on / off thing there should be some method of this being put in if on. I'm not sure but just having on seems not good if we allow it to be switchable.

Attachments (1)

responsive.diff (2.4 KB) - added by karmatosed 12 years ago.

Download all attachments as: .zip

Change History (18)

#1 @modemlooper
12 years ago

Tested and theme is worse off than having regular theme and zooming in. There defiantly needs to be a mobile css file to fix layout issues if you want to add responsiveness.

#2 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to 1.6

Confirmed that at least some devices are just rendering a zoomed-out version of the page. Adding the suggested meta tag does make it zoom, but as modemlooper suggests, a fair amount of work is needed to clean things up. Moving to 1.6 for more patches and discussions.

#3 @karmatosed
12 years ago

Rather than a mobile CSS file just using some media queries will work. I'll take a look at some myself see what can be done to at least patch some. It's not that bad just a few edges that do stick out I agree and need dealing with.

#4 @karmatosed
12 years ago

  • Owner set to karmatosed
  • Status changed from new to assigned

#5 @johnjamesjacoby
12 years ago

We have some responsive.css files in bp-default already. If we can clean this up for the 1.5 branch, I'd like to get this working correctly sooner than later.

#6 @karmatosed
12 years ago

Actually the issue of the loading viewport is a point covered looking at the theme by this:

// Responsive layout
	if ( current_theme_supports( 'bp-default-responsive' ) ) {
		wp_enqueue_style( 'bp-default-responsive', get_template_directory_uri() . '/_inc/css/responsive.css', array( 'bp-default-main' ), $version );

		if ( is_rtl() )
			wp_enqueue_style( 'bp-default-responsive-rtl', get_template_directory_uri() . '/_inc/css/responsive-rtl.css', array( 'bp-default-responsive' ), $version );

So rather than another test we can in the header just do a current_theme_supports check and output - easy :)

I should have a patch weekend for this using that as a basis assuming nobody objects or thinks another way is better?

Last edited 12 years ago by karmatosed (previous) (diff)

#7 @modemlooper
12 years ago

returns true if user is using one of the following mobile browsers
var ismobile=navigator.userAgent.match(/(iPad)|(iPhone)|(iPod)|(android)|(webOS)/i)

#8 @karmatosed
12 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

I've attached a diff file using the already existing function as seemed to make sense for now while that is used. I did a few formatting changes and so on but would encourage others to test what I did to ensure it works.

To summarise my changes:

  • Widget padding
  • Footer floating of widgets
  • Images being a % so reduce and show all image up to maximum size
  • Added in a meta viewport so it fits natively

I would also highlight that the 3rd and 4th level menus are a bit of an issue. My suggested solution for this would be to use this:

#9 @cnorris23
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Unless I'm missing something, this isn't actually fixed yet.

#10 @karmatosed
12 years ago

It has a patch, didn't see a has patch mark so sorry about mis flagging if that is an issue. If you want to test would love people to test the patch I've added.

#11 @cnorris23
12 years ago

  • Keywords has-patch added

No worries. Tickets are only closed as fixed when code has been committed to actually resolve a bug or an enhancement. "Workflow Keywords" is where you would designate that a ticket has a patch, or any other relevant keyword.

#12 @DJPaul
12 years ago

  • Milestone changed from 1.6 to 1.5.2
  • Severity changed from normal to major

#13 @DJPaul
12 years ago

  • Keywords needs-testing added

#14 @boonebgorges
11 years ago

  • Milestone changed from 1.5.2 to 1.5.3

#15 @DJPaul
11 years ago

  • Milestone changed from 1.5.3 to 1.6

#16 @johnjamesjacoby
11 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [5733]) Tweak responsive styling of bp-default. Fixes #3606. Props kamatosed.

#17 @DJPaul
7 years ago

  • Component changed from Appearance - Template Parts to Templates
Note: See TracTickets for help on using tickets.