Buddypress Comments Cornerstone conflict with iOS

Support
#1

I’ve been wracking my brain all day trying to get the comment functionality to work in buddypress with Youzer and Theme X.

The conflict is with Cornerstone and Youzer. Two very complex pieces of code.

It works fine on the desktop, including Google Developer and Firefox Developer when in mobile mode, but no love on any of my iOS devices or my friends. Tablets too.

So the question here is - how can I troubleshoot this? I can’t see any errors on my phone, and they’re not showing in my consoles in my developer browsers / tools.

Its a huge functionality issue. Downright show stopping, not to be able to comment on an activity stream Do you have some suggestions as to how to find the conflict and fix it? Is there anything on iOS that logs whats happening?

thanks

#2

Hi @bluedotproductions,

Thanks for reaching out.

It’s a known issue for touch devices and recently fixed internally, but we haven’t released any update related to it. Would you mind providing a sample URL where I can test, perhaps a test and comparison to what has been fixed will help and maybe I could provide a temporary workaround?

Thanks!

#4

Thanks for your patience @Rad. I was in the middle of a huge site move that I had to finish up before coming back to this. However I have better information!

I was able to create a dev sandbox for us to see the issue in.
Theme X 7.1.2
Cornerstone 4.1.2
Buddypress 5.1.2
Youzer 2.15

I have found that it is not isolated to iOS, but happens in Android as well through our users.

We may have a work around for our production site, and that is that it appears that
/wp-content/themes/x/framework/dist/js/site/x.js is the culprit, and when we turn it off via PerfMatters, the commenting and replying works on mobile. I think this has to do with X menu system.

We are using a side FlyMenu instead of X’s standard mobile menu when on phones. Perhaps you could help us come up with an easy way to turn off x.js on all mobile devices, and that would solve our problem until this could get developed out? However, we do want to keep the X menu in the center of the page as was designed for desktop.

I will put all credentials for dev site private. Thanks again for your help.

ri

#5

Hi @bluedotproductions,

I can confirm that this bug is already fixed and should be available on the next update. The x.js shouldn’t be removed as it’s a compiled script for multiple functionalities instead of just for menu and links. Though, thanks for sharing and I found another bug related to it (preventDefault() that requires double-tapping). I’ll continue checking to see if there is a temporary workaround and let you know.

Thanks!

#7

Hi @bluedotproductions,

I found out that this is a recent issue (or not so recent, but major libraries aren’t implementing it on their end as of yet) caused by browser updates, that’s why our previous fixes are no longer working. Please check this https://stackoverflow.com/questions/39152877/consider-marking-event-handler-as-passive-to-make-the-page-more-responsive

And this new feature https://developers.google.com/web/updates/2017/01/scrolling-intervention

On our theme, there is a recent bug fix (which we not yet released) and it fixes the conflict between 3rd party plugin (such as BuddyPress) to work with theme’s scrolling. Which means upon clicking, it opens the reply form then scroll it, this helps the user to set focus on reply form automatically instead of manually scrolling it.

But now, with the recent browser changes, this is no longer possible. In an element with multiple bound events, it’s executed one at a time. The first tap will open the reply form, the second tap will then scroll it. The jQuery library suffer with this issue, especially the Wordpress’ jQuery as mentioned from that discussion.

In your setup, the solution is turning off touchend events

jQuery( function($) {

$(document).ready( function() {

$('a[href*="#"]').off('touchend');

} );

} );

It’s the same fix added for that issue on our unreleased version, but it’s no longer working as well due to browser intervention. The fix is making sure the jQuery has the ability or option to control passive events (browser new feature). But unfortunately, it’s not yet available, even Wordpress is still using older version of jQuery. Another solution is staying away from jQuery, but that would require major changes in the theme :slight_smile:

I’ll continue the investigation, but this is far as I can cover for now.

Thanks!

#8

Hi @bluedotproductions,

Could you try replacing your file /wp-content/plugins/cornerstone/assets/dist/js/site/cs.fa34ec9.js contents with the one from here https://www.dropbox.com/s/ylcuwf53mr1g9tb/cs.fa34ec9.js?dl=0

Then please test it again and let me know :slight_smile:

Thanks!

1 Like
#9

Alas. The commenting works, but the reply just shifts a little without the box showing up. Similar to before.

It may be a strange work around - but a webmaster has to do what a webmaster has to do when they have thousands of paying members right?

I found that for us, the Cornerstone plugin didn’t seem to cause the issues - but x.js did. I ended up turning of x.js for mobile and all is working. I went with a 3rd party flymenu and all is working for our members. It is a kludge, and would love to fix it correctly some day!

   function x_enqueue_site_scripts() {

if ( wp_is_mobile() ) {
	
	if( ! bp_current_component() ) {
		
		wp_register_script( 'x-site', X_TEMPLATE_URL . '/framework/dist/js/site/x.js', array( 'jquery' ), X_ASSET_REV, true );
		wp_enqueue_script( 'x-site' );
		
	}
	
}

if ( is_singular() ) {
	wp_enqueue_script( 'comment-reply' );
}

}

add_action( ‘wp_enqueue_scripts’, ‘x_enqueue_site_scripts’ );

#10

Hi @bluedotproductions,

That’s weird, perhaps it’s caused by the combination of existing scripts from the theme and 3rd party plugins. The cause the issue is within the file that I provided, you can also check this related thread https://theme.co/apex/forum/t/i-cant-comment-or-reply-with-buddypress-on-physical-telephone/69982

And as part of the fix, I added this

if ( $target.is(":visible") ) {

}

To prevent shifting as I noticed that too while I’m investigating it. Would you allow me to disable all other features/plugin of your site for further testing? And please let me know which device you’re using for testing. And have you tried clearing browser cache after testing? It’s because the browser will use the same file it was downloaded if the requested file name and version is the same.

Thanks!

#11

Hi @bluedotproductions,

Indeed, it’s still shifting on some mobile devices. Let me explain why :slight_smile:

The /framework/dist/js/site/x.js file has integration with cornerstone/assets/dist/js/site/cs.fa34ec9.js, the theme’s x.js calls functions from cornerstone. Hence, removing or disabling x.js also disables the integration between them making it appears that the issue is in x.js, but it is not. The issue lies within the browser as it’s trying to stop e.preventDefault().

Every browser action has its own default behavior, like example, a form default behavior is to submit and reload the page, and a link default behavior is of course to link (if there is a link), or snap to the area where the anchor name matches (eg. if link has #name).

Now, it’s essential for an app to prevent those default behavior by adding e.preventDefault(), like instead of submitting a form and reload the page, it stops it for doing so, instead, user create another script that creates AJAX request based on form filled data and send it to the server without a need of reloading a page. It’s known implementation on web apps, even on Contact Form 7 plugin where it uses AJAX. Now, the form doesn’t have issues with preventDefault(), I just use it as a sample of the default behavior which can be turned off using e.preventDefault().

Now, back to the links where it uses anchor name and this is what happened.

Links

  1. Default: Link and snap (like if the matching form or area is located at the footer, then clicking the link will shift the scroll/focus to the footer immediately), again, this is a browser behavior but can be turned off
  2. Buddypress integration: Where it opens the form upon click instead of linking
  3. Theme’s integration: Instead of snapping on position, it creates a smooth scrolling effect.

Now, what it needs is just #2 and 3# to open a form and scroll it since we added preventDefault(), just like in here. But some browser ignores e.preventDefault(), then the #1 is executed along with #2, #3 causing the shifting. But I’m still investigating this, though, it will be a quite a battle since most of it is the restriction of the browser and the script library being used :slight_smile:

And thanks for sharing your temporary solution.

Thanks!

1 Like
#12

I appreciate your working on this, and if there is anything I can do to assist - i am happy to help make it work well on our next update.

I haven’t noticed any functionality loss with un-enqueing x.js on mobile. If there is anything I should look out for, I would appreciate your knowledge of this.

Thanks

#14

Hi @bluedotproductions,

Unfortunately, I’m still stuck on browser restriction as it can’t be turned off by any coding. Perhaps there is a way that we still can’t find :slight_smile: , we’ll sure fix it once we find something.

As for the functionality, the x.js is responsible for these

  1. Standard header search
  2. Woocommerce notification and ratings
  3. Masthead functionality related to slider, videos, and masonry layouts
  4. Header dropdowns
  5. Sticky bars

And many more. But if any of those features aren’t utilized on that specific page then it should be just okay.

Thanks!

#15

Just to give our temp solution - we made x.js queue only on desktop. Most of the functionality of x.js is not used on our mobile site.

Unfortunately, this required modifying a core file in X until a fix is available.
/wp-content/themes/x/framework/functions/frontend/scripts.php Line 19

function x_enqueue_site_scripts() {
		if ( !wp_is_mobile() ) {
			  wp_register_script( 'x-site', X_TEMPLATE_URL . '/framework/dist/js/site/x.js', array( 'jquery' ), X_ASSET_REV, true );
			  wp_enqueue_script( 'x-site' );
		      			}
  if ( is_singular() ) {
    wp_enqueue_script( 'comment-reply' );
  }
}
add_action( 'wp_enqueue_scripts', 'x_enqueue_site_scripts' );
#16

Hi @bluedotproductions,

Thanks for sharing, still some functionality may not work especially the one that meant for mobile since it’s now disabled for mobile with that implementation.

Perhaps, we can just completely turn off the integration with BuddyPress’ commenting area so you wouldn’t need to disable x.js completely.

Thanks!

#17

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.