About: Marko

I figured it out.

It wasn’t a plugin conflict, it wasn’t a theme conflict, it wasn’t mu-plugins. It was the APC on the server. I tried adjusting apc.mmap_file_mask, apc.shm_size values in apc.ini, but nothing worked.

I always knew that APC was throwing so many warnings on my server by looking at error logs from time to time. The most frequent warning I see in my logs is:

PHP Warning:  require_once(): Unable to allocate memory for pool....

Even after disabling W3TC plugin, the warnings were still getting generated in bulk. I though, if i could only get rid of that APC all together….

That’s exactly what I did and that FIXED THE PROBLEM!

SO I disabled APC completely by placing the following line in .htaccess file:

php_flag apc.cache_by_default Off

Although I don’t like this solution, it’ll do for now. I do want to have some sort of caching in place. I can’t believe that APC is the “go to caching” for PHP, I’ve had nothing but headaches with it.

Can you guys recommend any other caching mechanism that works well with s2member?

Marko

I should use the word “verification” instead of “confirmation”.
To clarify, I would like users to verify their email address by clicking on a link in their inbox, which activates their account.

Is this feature supported? If not, is there a way to prevent users from entering random email addresses in a Pro Form and logging in immediately after they register?

The logs say everything is fine. Pasting the output below. I’ve replaced sensitive information with generic stuff, i.e. first_name, last_name, api_key etc…

array (
  'function' => 'process_list_servers',
  'func_get_args' => 
  array (
    0 => 's2member_level1',
    1 => '1',
    2 => 'username',
    3 => 'friendly_name',
    4 => 'email',
    5 => 'first_name',
    6 => 'last_name',
    7 => 'ipaddress',
    8 => true,
    9 => true,
    10 => 74,
  ),
  'api_method' => 'listSubscribe',
  'list' => '108cc65ee3',
  'list_id' => '108cc65ee3',
  'merge_array' => 
  array (
    'MERGE1' => 'first_name',
    'MERGE2' => 'last_name',
    'OPTIN_IP' => 'ip_address',
    'OPTIN_TIME' => '2012-11-02 02:24:10',
  ),
  'api_merge_array' => 
  array (
    'MERGE1' => 'first_name',
    'MERGE2' => 'last_name',
    'OPTIN_IP' => 'ip_address',
    'OPTIN_TIME' => '2012-11-02 02:24:10',
  ),
  'api_email_type' => 'html',
  'api_double_optin' => true,
  'api_update_existing' => false,
  'api_replace_interests' => true,
  'api_send_welcome' => false,
  'api_response' => true,
  'api_success' => true,
  'api_properties' => 
  NC_MCAPI::__set_state(array(
     'version' => '1.3',
     'errorMessage' => '',
     'errorCode' => '',
     'apiUrl' => 
    array (
      'scheme' => 'http',
      'host' => 'api.mailchimp.com',
      'path' => '/1.3/',
      'query' => 'output=php',
      'prefix' => 'us5',
    ),
     'timeout' => 300,
     'chunkSize' => 8192,
     'api_key' => 'api_key_here',
     'secure' => true,
  )),
)

:-/

Actually I just tested level 2 registrations as well. They also assign users with a Subscriber level 0. Am I doing something obviously wrong? This worked perfectly before.

I do have heavy wp-super-cache in place and I’m wondering if that has something to do with this.

• This reply was modified 4 years, 2 months ago by  Marko.

Please do :-)
It would be great to be able to prevent the redirection!

Awesome. Thanks for the tip!