Skip to:
Content

BuddyPress.org

Opened 9 years ago

Closed 9 years ago

Last modified 4 years ago

#3606 closed defect (bug) (fixed)

BuddyPress default isn't responding to devices size wise

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

Description

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 9 years ago.

Download all attachments as: .zip

Change History (18)

#1 @modemlooper
9 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
9 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
9 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
9 years ago

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

#5 @johnjamesjacoby
9 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
9 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 9 years ago by karmatosed (previous) (diff)

#7 @modemlooper
9 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
9 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:
https://github.com/mattkersley/Responsive-Menu

#9 @cnorris23
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#10 @karmatosed
9 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
9 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
9 years ago

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

#13 @DJPaul
9 years ago

  • Keywords needs-testing added

#14 @boonebgorges
9 years ago

  • Milestone changed from 1.5.2 to 1.5.3

#15 @DJPaul
9 years ago

  • Milestone changed from 1.5.3 to 1.6

#16 @johnjamesjacoby
9 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
4 years ago

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