Jason (Lead Developer)

Thanks for the heads up on this thread.

There have been no significant issues with the current release of Quick Cache, and since we’re hard at work on a new/improved version of Quick Cache, we’re not currently updating the existing release. If significant issues arise, you can be sure we’ll address them.

The new release of Quick Cache will also be provided at WordPress.org. There WILL be a free version of the next major release. No worries. You’ll be notified in your Dashboard automatically. We’re a little behind schedule, but we’ll get there soon.

Thanks for the heads up on this thread.

I just made an attempt to reproduce this, but I was unable. The additional query string argument s2member_level_req=1 is for information purposes only (for developers); as discussed here:

Dashboard -› s2Member® -› API / Scripting -› Membership Options Page Variables (MOP Vars).

Did you ever figure out why this was causing a blank page on your site? I see you removed the variable, but I’ve been unable to determine why that variable would have caused a blank page. Do you have a custom .htaccess (or any s2Member hacks) you can post for us? Those could be the underlying issue on your installation?

Thanks for the heads up on this thread.

And although the correct data is sent to Mailchimp, it doesn’t stick in the WP user record. Within the filter, if we call get_user_option() again after calling update_user_option(), it returns the updated information. But when we go back to the list of users in the WP admin interface, it’s still got the old values.

Have we missed something?

It sounds to me like you’re using this filter for MailChimp, to not only affect the MailChimp MERGE vars, but also to update a user’s record at the same time. While it’s certainly possible to do this, I would’nt do it all inside a filter attaching to ws_plugin__s2member_mailchimp_merge_array, because that is merely a filter for a specific array of details being passed over to MailChimp.

The reason you’re seeing details properly while in your custom function that’s working together with this filter, but they’re NOT sticking, is because WordPress and s2Member are actually still in the process of registering/updating the user’s account record with a completely different set of information, which does not include the custom data you’re attempting to save upon hooking into this filter.

So the solution in a case like this, is to use the MailChimp filter only for what it’s designed for. Then use a Hook provided by WordPress or s2Member to actually save the data to the user’s account record, at the appropriate time (i.e. using a Hook that puts you right in the action, where WordPress/s2Member are actually handling the customer’s details).

I recommend this hook to save user data during registration.

By default, on a Multisite Network (without s2Member)…

User registration, if allowed, occurs through /wp-signup.php, regardless of which blog is being accessed, all registrations would go through /wp-signup.php. In addition, the Network Settings menu where you’re asked “Who Can Register” would affect all sites (i.e. all Child Blogs) in the Network.

Without s2Member installed, Network-wide registration settings are handled via:
Network Admin -> Network Settings -> Who Can Register.

With s2Member installed on a Multisite Network…

s2Member’s Multisite Patches are applied, and we remove this limitation. It now becomes possible to collect registrations for each blog separately. Making it possible to accept registrations through either /wp-signup.php on the Main Site of your Network, or through /wp-login.php?action=register on each Child Blog, or even on the Main Site if you prefer; /wp-login.php?action=register can be used on the Main Site too.

In addition, if s2Member Pro Forms are used, registration can occur through a Pro Form introduced on-site. So, if you prefer to take more control over the registration process, it’s possible to do this with s2Member Pro Forms.

With s2Member installed, Network-wide registration settings are a moot point. This section in your Dashboard: Network Admin -> Network Settings -> Who Can Register is disabled, and instead of setting Open Registration here, you can handle this setting for the Main Site of your Network under: s2Member -> Multisite (Config) -> Multisite Registration -> Main Site / Open Registration.

For each individual blog, Open Registration is disabled by default, but can be enabled if s2Member is activated on a Child Blog, by going to s2Member -> General Options -> Open Registration on that Child Blog where s2Member is active (if it is active on that Child Blog). If s2Member is NOT active on that Child Blog, Open Registration is off by default, as it should be.

Understanding s2Member’s Multisite (Config) Panel…

The option you choose there for “Main Site / Open Registration”, is ONLY applied to your Main Site. It does NOT affect Child Blogs that exist now, or that you might add later, in any way at all. Open Registration is NOT enabled for any of your Child Blogs by default. By default, Open Registration is disabled for each Child Blog, as it should be.

Helpful Hints, Tips & Tricks on a Multisite Network…

If you are logged in as an Administrator (or Super Admin), registration will appear open across the Network, because it’s YOU who are browsing and testing the sites. Please make sure you log out of the site before testing any user/member/registration functionality in your Network.

If s2Member is NOT active on a Child Blog, and for whatever reason Open Registration is enabled on a particular Child Blog, a Network Administrator can change this from the Network Admin panel. Open Registration is ALWAYS off by default, but if settings for a particular Child Blog have been corrupted or manipulated by plugins you’ve experimented with, it might be necessary to change this setting manually. See: Network Admin -> Sites -> Edit -> Settings, as depicted in the screenshot below. 1 is on, 0 is off, the default value.

If s2Member has been activated on a Child Blog, or was activated Network-wide, so it’s active on every Child Blog of the Network; Open Registration can be controlled for each Child Blog by logging into that Child Blog, and going to s2Member -> General Options -> Open Registration.

Thanks for the heads up on this thread.

I’m having the code samples for JW Player updated in the next maintenance release to include the mp4: prefix for streaming distributions. You’re right, it works fine from the root bucket, but not from a directory, not in the latest version of CloudFront. This seems to be a change in the way the latest versions of the CloudFront API handle streaming requests, indicated by this article.

Thanks for the heads up on this thread.

This is a question for MailChimp® please. We integrate with MailChimp®, we don’t enforce their rules, or make efforts to interpret their terms/conditions. Please see: http://kb.mailchimp.com/contact

Thanks for the heads up on this thread.

Hi Bart. We’re already on this. Support for your new services in the UK are forthcoming on our end. We’ll let you know if any problems arise. Thanks for your contact information, we appreciate that!

You’re VERY welcome.

You can use %%user_email%% or %%user_login%% if you prefer. Here is a link that tracks the order number as the user’s username (i.e. %%user_login%%). See also: Dashboard -› s2Member® -› API / Notifications -› Registration Notifications for a list of all Replacement Codes.

http://www.sippclub.com/idevaffiliate/sale.php?profile=72198&idev_commission=1.00&idev_ordernum=%%user_login%%&idev_option_1=%%user_id%%&idev_option_2=%%user_login%%&idev_option_3=%%cv0%%&ip_address=%%user_ip%%

I recommend NOT using the email address as the order number within iDevAffiliate. If you must use one of these, I’d go with the username (just use the link above), because exposing a customer’s email address in affiliate reports would be a privacy issue for you.

@ George Fourie

Thanks for reporting this important issue.

Please confirm for me…

You are running s2Member v121213 or higher, correct?
http://www.s2member.com/changelog/#s2-changes-v121213

Also, what error message are you receiving please? If it’s a writable file error, please set permissions on /wp-login.php to 777 via your FTP application and then re-run s2Member’s multisite patcher.

case 'register' :
	if ( is_multisite() ) {
		// Multisite uses wp-signup.php
		wp_redirect( apply_filters( 'wp_signup_location', site_url('wp-signup.php') ) );
		exit;
	}

Change that to:

case 'register' :
	if ( is_multisite() ) {
		// Multisite uses wp-signup.php
		// Modified for full plugin compatiblity.
		//wp_redirect( apply_filters( 'wp_signup_location', network_site_url('wp-signup.php') ) );
		//exit;
	}

Thanks for the heads up on this thread.

s2Member’s integration with Authorize.Net does NOT allow you to create Custom Registration/Profile Fields from your s2Member configuration panel, and map those to Authorize.Net API calls. s2Member only sends Authorize.Net the information required to complete the transaction itself. All other information (i.e. any Custom Fields that you add), will be stored in WordPress and associated with the customer’s account record in WordPress, and only in WordPress.

That being said, you are correct that Authorize.Net DOES support a company field. So if you wanted to map your Custom Registration Field that you created with s2Member to an API call that passes that info over to Authorize.Net, you will need to custom code this.

Here is a quick overview of what it might take…

Open /s2member-pro/includes/classess/gateways/authnet/authnet-checkout-in.inc.php

Find all lines which contain:

$_authnet["x_first_name"] = $post_vars["first_name"];

Add a line beneath each instance that you find.

$_authnet["x_first_name"] = $post_vars["first_name"];
$_authnet["x_company"] = $post_vars["custom_fields"]["company"];

This assumes that you gave your Custom Registration/Profile Field (when you configured it with s2Member), the Field ID: company. If you did NOT give it this Field ID, then please change the code snippet above where you see reference to the Field ID (i.e. ["company"]).

See also: Dashboard -› s2Member® -› General Options -› Registration/Profile Fields

Thanks for the heads up on this thread.

It is generally NOT harmful to delete s2Member transients, because these contain only temporary data that is not absolutely necessary to the functionality of s2Member over the long term. So what you did is fine. However, please note that after deleting s2Member’s transients, you’ve also reset your IP Restrictions for s2Member, as s2Member uses transient details to track customer behavior over a 30 day period (30 days is the default configuration). See: Dashboard -› s2Member® -› Restriction Options -› Unique IP Access Restrictions

Each transient is associated with an expiration date in the DB, and s2Member will automatically purge these from your DB over time via WP Cron. Having thousands of transients would NOT be uncommon on a site where there are MANY users. I’m not aware of any performance impact with this either. The use of transients would need to reach the 100’s of thousands (or more than a million in many cases) before most sites would even begin to feel a strain of any kind with this. WordPress does not autoload transients, they are just in the DB for reference as needed, and take up very little space.

_transient_s2m_ipr_9956e1a3022e58d… (tracks customer IP addresses)
_transient_s2m_rtn_2c71b18200b7fb1… (helps to prevent duplicate return-page handling)
_transient_s2m_ipn_c34f8253d048595… (helps to prevent duplicate IPN processing)

NOTE: WordPress does NOT automatically delete transients over the long term. s2Member handles this via WP Cron. It is a common assumption that WordPress will purge transients from your DB via WP Cron using a default installation of WordPress. That is NOT the case (not with a default WordPress installation). A plugin must provide this functionality, and s2Member handles transient cleanups via WP Cron for you.

Each transient in the DB has two rows.

_transient_s2m_.... (the data being stored)
_transient_timeout_s2m_... (the timeout/expiration value)

Hi Donald. Thanks for purchasing s2Member Pro!

I’m sorry but if you purchased before the special promotion began, we will be unable to offer you the same discount. Doing so would be unfair to anyone/everyone who purchases before or after special promotions are made available here at s2Member®. Again, very sorry. Bending the rules on this will cause us problems.

This latest promotion started on: Dec 14th, 2012
It ends: Dec 31st, 2012

Thanks Ross!

Yes, you are correct here.

So the scenario of upgrading BBPress when S2 IS already active might not run that routine to link the roles?

I’m guessing that on each S2 upgrade that routine is automated, but when BB Press is updated and reactivated we may have to push that button to run the routine?

An upgrade of bbPress (where a new version of bbPress is introducing role changes), will require you to press that button again so that s2Member can get things updated, with respect to Roles. s2Member will do this automatically whenever IT is upgraded, but if bbPress were being upgraded, without also updating s2Member immediately after, clicking that button in s2Member would resolve the issue for you.

In short, you are absolutely correct!

For the benefit of other readers, we’re speaking of the button located here:
Dashboard -› s2Member® -› General Options -› Membership Levels/Labels
Click the button at the bottom of that section to reinstall your s2Member roles.

s2Member also makes a button available in the s2Member® -› Other Integrations section of it’s control panel, which does the exact same thing. Both of these buttons reconfigure s2Member’s Role/Capability integration with WordPress/bbPress.