Issue with recent Upgrade

I upgraded this morning to the latest version s2Member Pro v120517 but now my log-in button and links to secure S2 Member client areas- activity, member profile do not work. I followed the upgrade instructions and my safeguard setting shows “Yes, safeguard all data options”. Is there a reason why my log-in button and other S2 Member pages would not work? I tried re-adding these pages to the menu and they still don’t work. Site is- http://greenwichtriclub.com

Thanks, Matt

Hi Matthew.

Could you verify that the plugin shows up correctly in the plugins list? Also verify that the Pro add-on is active too.

Thanks!

Yes, the plugin shows up correctly and is listed as-

s2Member®, a powerful (free) membership plugin for WordPress®. Protect/secure members only content with roles/capabilities.

Version 120517 + s2Member Pro v120517 | By s2Member® / WebSharks, Inc. | Visit plugin site

Also I have pro – add on active. After I updated I received the warning to update Pro and clicked through that and received the message it was updated successfully.

Okay.

Could you post the URL to the page with the problem and tell me which s2Member link/button is not working? Thanks!

The main site is http://greenwichtriclub.com. In researching further the problem occurs with the main site menu. Since I made the upgrade any menu item with a drop down does not work. For example “Triathlon Training” the second menu item, should have 2 sub menus but they do not show. One of the pages in the drop down should be http://greenwichtriclub.com/club-workouts/ which requires S2Member Level 2 or higher to view,, not sure if the membership requirement is causing the issue? but it would fine prior to the upgrade.

Also the login button was no longer working since the upgrade, I was using the popup login feature, however I have since created a new link to go directly to http://greenwichtriclub.com/wp-login.php so users can still use the site until the issues get corrected.

Thanks.

It may be a JavaScript conflict, could be the theme or another plugin.

This is part of a conversation I had with Jason some months ago regarding JavaScript conflicts.

Cristián: I still don’t understand how the JS conflicts work… If the library is the same in both plugins, why is there a conflict? Same var names?

Jason Caldwell: Well, I call it a conflict. Sometimes it’s a conflict in jQuery because of a bad plugin, which attempts to load jQuery on it’s own, instead of doing it the WP way. Or sometimes, it just a bad plugin that causes a JavaScript error, which may result in all JavaScript failing (the nature of JavaScript). Not really a “conflict” in that case, really an error due to a bad plugin/theme.

Jason Caldwell: I’ve also seen some conflicts between frameworks. That’s rare, but there are some plugins that use the ProtoType framework, and combined with another framework like MooTools, there is a possibility for a conflict to arise. Rare though, and it’s usually attributed to the way they’re loaded (i.e. by a bad plugin/theme).

Cristián: Does WP load JQuery already? If so, why do plugins load it too?

Jason Caldwell: Yea, WP already loads it. But some plugin authors don’t know that, or they just hard code it into their plugin not realizing that. Other times they’ll try to include a dependency on jQuery, but they name it wrong, and WordPress gets confused.

Cristián: Does s2Member load it again or uses WP’s?

Jason Caldwell: Hmm, not really, because in the Dashboard, it’s already loaded by WordPress. s2Member enques scripts that it uses, which rely on jQuery being present. In the call to wp_enqueue_script(), s2Member will list jQuery as a dependency, which forces WP to load it, though it’s already loaded in the Dashboard anyway. That’s the proper way to handle it.

On the front-end of a site, s2Member will load jQuery if it’s not already loaded, but again, using the same technique. A call to wp_enqueue_script() with a dependency on jQuery forces WP to load jQuery. If 10 plugins all do it this way (i.e. the right way), WordPress loads jQuery in the proper order and only one time.

Cristián: Ah, got it. I understand WP has a QC team, don’t they check this?

Jason Caldwell: Not in my experience. They look mostly for security issues and really bad code. They usually don’t catch minute details like this.

Cristián: I see, but these details do cause trouble for the users. Maybe it’d be good to write an article about JS conflicts as you explained above and post it in the forums, and then show it to the QC guys for consideration to include in their quality checklist.

Jason Caldwell: Yea, that’s a good idea. On the WP side though, they’re aware of this problem, and that’s why they created the wp_enqueue_script() wp_enqueue_style() functions. Although, I wish this were more prominent in this article: http://codex.wordpress.org/Writing_a_Plugin#Plugin_Development_Suggestions

It is mentioned, but it’s all the way at the bottom:

Try not to echo [hilite code]