Nabha Cosley

Well, you know what — that wasn’t quite true. There are other places where e.preventDefault() or e.stopPropagation() also interfere. I don’t think I can keep trying to figure it out at the moment, though.

For our purposes we can actually keep the preventDefault() in clickPagerBind() enabled, and comment it out everywhere else — and that works.

OK, I think this is my final post for now. Really.

The issue is in strongslider.js. There are three places I can comment out e.preventDefault() and e.stopPropagation() to make it work:

1. Line 1438 in onTouchMove()

      if (e.type !== 'touchmove') {
//         e.preventDefault();
      }

2. Line 1351 near the top of touchStart()

3. Line 1356-7, also in touchStart():

      if (slider.working) {
//         e.preventDefault();
//         e.stopPropagation(); // for compatibility with WordPress themes
        slider.controls.el.removeClass('disabled');
      }

All three places seem to be required to comment out.

Anyway, obviously this is catching clicks on the readmore link (in mobile browsers only — even desktop emulation through Chrome doesn’t seem to have the problem for me anymore) when it isn’t supposed to.

Happy to help test anything if you like.

• This reply was modified 5 years, 9 months ago by Nabha Cosley. Reason: Minor: Clarifying what desktop emulation meant

OK, one more update. The plot thickens. ??

We’re using the Modern theme. If I change the template from this:

<div class=”strong-view …

To this:

<div class=”asdf-strong-view …

… the links work. So granted that there’s a Cornerstone conflict, it’s also true that just changing this class name fixes the problem.

Of course it breaks all the CSS and JS too. But it means that there’s likely a solution that could be had within the Strong Testimonials plugin itself.

Anyway, hope that helps to know. Thanks!

• This reply was modified 5 years, 9 months ago by Nabha Cosley. Reason: Minor clarification in code

I mean, the testimonials work. Nothing else does ??

Whoops, an update: it looks like it’s a problem with Cornerstone by Theme.co — when I deactivate that plugin, everything seems to work.

The only solution I know of (which we’ve done, before) is to upload the images again over SFTP, then run the optimization immediately.

Also, if it helps, we had to use an AJAX thumbnail regeneration plugin so that the thumbnail optimization plugin wouldn’t time out.

Just thinking about this more… it would be better to join the categories table for pages only if that use has been requested.

So, if cats is set to any value and page is one of the requested post types… then $join_cats = true.

What do you think? Still happy to create a patch.

Oh, it turns out that the patch is trivial, thanks to your coding.

You just comment out lines 874 and 875:

//if ( strtolower($instance['post_type']) == 'page' )
//	$join_cats = false;

Aha, but pages *can* have categories, as mine do — it’s just not the default. Would you be willing to take a look at a patch for this if I created one?

Ah — category_name is in WP_Query, and for some reason I thought WPP supported WP_Query arguments, but I must have dreamed that up.

Realized I didn’t say: this is using WordPress 3.7.1 and the latest version of the plugin.

For a lot of people it has to do with plugin conflicts (as it did for me). You might explore that if you have any security plugins or SSL plugins.

Otherwise, it would be worth playing around with WooCommerce’s SSL settings on the General tab of the Settings page. Disable “Force SSL” or “Un-force SSL” for a moment to see if it fixes the problem.

Generally of course you WOULD want to force SSL to be on for checkout, because otherwise people might be sending you credit card info in an unsecure way.

Aha — I was using Force Password Change, which made sense in an earlier incarnation of the site.

Sorry Sharebear, that probably isn’t any help — but try providing whatever error message you are getting, maybe that would help people answer with the possible next steps for you.

OK, for me it happened because the password wasn’t properly set for the new account — even though I had typed it in, in the checkout process. That’s another bug to figure out, of course, but at least it sheds some light on what is going on.

Do you get any errors?

Customer accounts have been getting a redirect loop error on that same page, when I check “Prevent customers from accessing the WordPress admin” in the WooCommerce settings page.

In Chrome, I see:
Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

It looks like the My Account page is trying to redirect to the profile page for some reason. This doesn’t happen with my admin account.

FYI, the problem was this rule:

body {
    position: relative;
}

When removed, it works fine.

Thanks again.