BuddyPress default isn't responding to devices size wise

[karmatosed]

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.

[modemlooper]

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.

[boonebgorges]

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.

[karmatosed]

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.

[johnjamesjacoby]

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.

[karmatosed]

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.

[modemlooper]

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

[karmatosed]

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

[cnorris23]

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

[karmatosed]

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.

[cnorris23]

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.

[johnjamesjacoby]

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