S2member-o.php jquery loading issue [here, because may interest everyone]

Different than any of the three that currently come up in search for “Uncaught ReferenceError: jQuery is not defined
at s2member-o.php:1”

So the topic: How do you best get round this?


  • the error comes up in browser console ONLY when on the “membership options page” or any page BELOW that. On all other pages jquery is loading fine.

  • I am not even sure the lack of jquery having loaded in time is a real problem: eg when a user navigates a locked page and s2m refers him to membership options page, the url query string is clearly visible/working:

  • Jason gave a very interesting explanation of s2member-o.php here:

  • For speed reasons, WE load jquery only on a couple pages early (for plugins that need it), all other pages load jquery defered in the footer.

  • s2member-o.php seems to also (unintentionally) either prevent jquery loading, OR what I rather suspect, jquery gets loaded too late for s2member-o.php to notice. [remember here: on ALL pages other than on/below membership options page we have no errors]

What do others experience?

  • Should s2m users care about that jquery is not defined on membership options page?
  • or should they load it on that page in the header?
  • or not bother because/IF the lack of jquery on membership options page doesn’t actually impair functionality?

Any thoughts?

There is simply no point in loading jQuery in the footer. If you are going to make reliable use of it, it must be loaded in the header. So what you are doing on those page is the equivalent of not loading it at all while still taking the overall performance hit.

I am sorry Tim, here you are 100% mistaken.
And sure enough we certainly aren’t taking “a performance hit” at all, our site loads quicker than any site of comparable size/pages, as literally every speed test site confirms.

If anything, I know how to make websites faster than … phew, anyone? Seen varvy.com from Patrick?
Pages similar size we load the same speed.

And yes, OF COURSE you load jquery intelligently in the footer wherever possible. That’s why I wrote “except for the pages that need it earlier”.
==> Shorten the critical rendering path wherever you can, and you achieve our speed, or Patrick’s.

So, no categorically “no’s”, rather: has anyone real suggestions as regards s2member-o.php?

Actually, just remembering:
Earlier we had it even that we didn’t load jquery at all until AFTER the page was fully rendered.

Contrary to what you read on the web, it IS very well doable. And all of wordpress worked fine with it, no question.

There’s a lot to learn how to redesign the wordpress load process to make sites fast. I would never categorically rule out sth aka “is the equivalent of not loading it at all while still taking the overall performance hit.”

I don’t think you understood my reference to a “performance hit.” You are still loading jQuery, so the page still takes that time to fully render. It’s just that, since javascript is render-blocking, you get to see the html before that occurs. But the performance hit of which I was talking is still there.

You say that you have your pages working with jQuery loaded in the footer. I don’t doubt that you do, otherwise you wouldn’t have mentioned it. But have you actually tried dequeuing it altogether? If everything still works, you’re loading it for no reason at all.

I doubt that. If you did, you’d be talking about Opcache, transients, and wp_cache for a start. They are the real way to speed up WordPress sites.

I don’t think you understand what I am saying, also you confuse “fully rendered” with “fully loaded” with “time to first interactivity” - which is what google & co measure and base your search ranking on.

How fast are your websites?

Once you see for every page of yours, even if loading thousands of images, consistently “your site is faster than 97% of sites tested”, you are doing fine: Then and only then, you will have understood what matters, and how to achieve it.

No offense, I just can’t reply more to these repeating views that you have, I am not trying to nor need to convince you of anything, just do what you think is right, okay?

Please do not continue to post in my thread here that has a totally different topic and question. Thank you, really thank you, because I posted to get answers to what I (I) asked. :wink:

What you seem to be completely overlooking is that, on any membership site, visitors don’t just visit one page. The significance of that is, after the first page loads, jQuery is cached in the browser. That means, for all subsequent visits to any other page on the same site, jQuery doesn’t re-load at all. Ever.

So what you think of as a clever trick for speeding up page loading does nothing at all after the first visit. Absolutely zero. (You can easily check this by looking at your browser tools when you visit a second page on your site.)

This is a great example of what happens if you treat speed testing websites as masters instead of tools. They only test a page as a one-off. That is fine for some sites, but useless as a measure of any membership site (especially if the content in the site is completely protected). If you want to speed up membership sites, you need solutions that are persistently helpful, and that means using OPcache, transients, and wp_cache.

Speed testing websites also typically give some terrible advice for modern websites. But, since that actually would be getting off topic here, I won’t go into them.

Diplomacy you don’t understand.
Politeness you don’t understand.


You have RUINED MINE, no one gonna bother sifting through your…
Now thank to you … I have to RE-post one!

(which likely you ruin again so bored you appear to be!)

You don’t appear to understand what this forum is. It’s not a support forum. It’s a community forum.

So posting helpful advice here is great. But when someone purports to advise others to do something which is completely wrong, that’s the very opposite of helpful. It will just break other people’s sites and waste their time and, as I said, you get no speed boost at all after first page load anyway.

You should not be telling people to load jQuery in the footer.

did you find a solution to this issue? I have the same problem on my site currently.

Funny enough, it’s loading fine on localhost, but on the server (exact same settings), I get a “jquery not defined” error.


Hi Jan, yes I did, this tim kaye guy went on my nerves, so i left.

You are polite so here I am, for you. - NOT FOR “TIM KAYE” TO DISTURB AGAIN! GET A LIFE! No wonder, websharks’ Jason, Cristian, and Ram disappeared as well!

Jan, Jquery loading in footer is totally fine and smart on all pages where jquery isn’t needed by some plugin or wp function earlier. It costs time to look in console for each plugin’s needs, but ultimately we got there:

  • we heavily use s2m: when someone visits a members-only page they are redirected to the s2m membership options page, so WE have to add s2m shortcode to exception list, others may not need to
  • below is the code I use in functions.php that decides when jquery gets loaded
  • note also that initially I did try with newer jquery libraries (all from google cdn) but for US some older plugins didn’t play well then
  • so, testing is key when you “tune” wordpress sites for load speed
  • we ended up making the site the fastest wordpress site at the time, as per tools like webpagetest.org, so what we do absolutely works well
  • before anyone starts arguing again: fastest not for a cleverly chosen page or homepage, but for the largest page, loading most assets (speed for that was some 479ms or so, of course + server TTFB).
  • this is what counts IMHO; anyone can turbo-prop an empty homepage…
  • code posting here doesn’t come up correctly, if you need contact me by email for all code
  1. In our s2hacks mu-plugins file we exclude all plugins that are only used on certain URLs anyway. That code has some private stuff but per email i would share it with you too. Generally it looks like so:
$request_uri = $_SERVER['REQUEST_URI'];
$is_admin = strpos($request_uri,'wp-admin');
// add filter in front pages only
if(false === $is_admin){add_filter('option_active_plugins','remove_unnecessary_plugins');}
function remove_unnecessary_plugins($plugins){
	global $request_uri;
	$uses_contact_form_7 = strpos($request_uri,'submit-an-entry') || strpos($request_uri,'...
  1. Then in functions.php we exclude those plugins that can’t be managed globally by url, so then by shortcode:
//Remove or Restrict scripts and styles to load only when needed
function remove_ticks(){
	global $post;
	if (!is_admin()){
//give special treatment to online health assessment, discussion=true, and shortcodes sociallocker, s2, show-quiz; for others load jquery in footer deferred
		if ((false === strpos($_SERVER['REQUEST_URI'],'german-shepherd-dog-health-assessment-online')) && (false === strpos($_SERVER['REQUEST_URI'],'discussion=true')) && (!has_shortcode($post->post_content,'s2')) && (!has_shortcode($post->post_content,'sociallocker')) && (!has_shortcode($post->post_content,'show-quiz'))){
//Add defer/async attribute to scripts - to find their js-handle search files for: wp_register_script, and for: wp_enqueue_script
			function add_async_defer_attribute($tag,$handle){
				if ($handle == 'jquery') {return str_replace(' src',' defer="defer" src',$tag);}
				return $tag;
		else {
		wp_deregister_script('wp-embed'); //never call wp-embed.min.js because we don't embed posts from other wp sites
		if (!has_shortcode($post->post_content,'video')){
// wp_deregister_style('magnific');
add_action('wp_enqueue_scripts','remove_ticks',12); //with late priority so that it is after the script was enqueued
  1. Then in footer.php we ensure to load “all crap” only after the page is rendered and ready for “first user interaction”, because this is how google assesses load time, says Patrick Sexton, https://varvy.com
if (window.addEventListener) window.addEventListener("load",downloadAllCrapOnload,false);
else if (window.attachEvent) window.attachEvent("onload",downloadAllCrapOnload);
else window.onload=downloadAllCrapOnload;
function downloadAllCrapOnload(){var csslast=document.createElement('link');csslast.rel='stylesheet';csslast.href='/wp-content/themes/gsd/custom/css-below-the-fold.css';csslast.type='text/css';var defercss=document.getElementsByTagName('link')[0];defercss.parentNode.insertBefore(csslast,defercss);if(!window.jQuery){var mya=document.createElement("script");mya.type='text/javascript';mya.async=false;mya.src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js";document.body.appendChild(mya);} var deferimg=document.getElementsByTagName('img');for(var i=0;i<deferimg.length;i++){if(deferimg[i].getAttribute('data-src')){deferimg[i].setAttribute('src',deferimg[i].getAttribute('data-src'));deferimg[i].removeAttribute('data-src');}} var myb=document.createElement("script");myb.type='text/javascript';myb.async=false;myb.src="https://checkout.stripe.com/checkout.js";document.body.appendChild(myb);var myc=document.createElement("script");myc.type='text/javascript';myc.async=false;myc.src="/wp-content/themes/gsd/scripts/mygsdorg_final.js";document.body.appendChild(myc);}

That’s it. All of this works like a charm. Took many months to figure out though.

Whenever you add a NEW plugin thereafter, you have to investigate its code / loading though. I guess that’s the job of a webmaster though?

Actually all this taught us to pre-evaluate any plugin before purchase whether it can match our new standards. Most plugins are programmed like crap, it seems. - hence why testing took months…

Hope this helps you too.


That’s a complete answer, nice job :slight_smile:

Thanks, David!
I appreciate your detailed answer :slight_smile:

Just opened a new thread with my issue, before I saw your reply. I’ll see if I can get it to work following your advice. If I can, I’ll link your answer in my new topic and will close it.


For reference, in my case the Rocket Loader function from CloudFlare caused the issue.


You saved my day! My exact issue. Thanks!

1 Like