Cristián Lávaque

The error wouldn’t even happen with the player, because the player would only be shown to those with access to the file if you use the conditional the way I said earlier. :)

Just sent you an email, you can reply to it with the login info.

Got it on not being able to change the theme. There’s a plugin that lets you change the theme for a single page, but I think it’d be best if you could install a new WP in another folder to test this and see if you can get the restriction working there. And then add the theme and other plugins until it breaks, in order to find what’s causing the problem.

Cool. Glad I could help. :)

Please let us know how it goes!

Okay…

One more test, please. Could you try using the default TwentyEleven theme? I’m wondering if the theme is affecting the s2Member restriction in some weird way.

If that doesn’t work, I’m going to ask you to email me your login info so I take a look at your installation to try finding what the problem is, if you’re okay with that.

Hi Lisa.

I see what your problem is. The documentation in the User Import panels should help. [hilite path]Dashboard -› s2Member® -› Import/Export -› User/Member Importation[/hilite]

I suggest that you create a user with all the custom profile fields filled out, don’t leave them without a value or they won’t be in the CSV, and then export your users. Go take a look at how this test user’s row looks like and use it as your template for your users when importing them.

Basically, you need all the columns s2Member expects when importing a user, and in that order, even if you’re using column labels. And the custom profile fields are done in pairs of columns: field name, field value. It’s an unconventional format which we will change to a more standard one in the new s2Member, but it’s the one we have right now.

I hope that helps solve the difficulty you’re having with it right now. :)

I’m glad you found the conflicting plugin so quick! I’m sorry it’s one so important to your site, though. But it may be possible to fix it without much trouble.

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 see 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 their 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 is 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. Well, they do look at how the db is used, iirc.

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]