rossagrant

Will do, thanks so much for your help!

In the meantime, if anyone runs their site like this with S2, please shout up!

I’d love to hear of working solutions!

At the moment i use a very standard set up of S2 member.

Users either sign up for free initially or hit a PayPal button to sign up for S2 level 1 access.

If they do this initially they go to Paypal and are redirected back to the registration form on successful payment.

The registration form in each instance is exactly the same – the standard BP form.

I haven’t altered any of the core BP registration stuff at all.

My concern about moving away from this form to one that can handle conditional logic is that the form might dictate the user level and not let S2 deal with it as it does with the default registration page.

AWESOME! And no worries whatsoever on timeframes. When you are developing something that’s free for us, no one can expect you to jump right at it!

Thank you so much for a fix, it’s VERY MUCH appreciated!

Have a great weekend! 🙂

Hey Joost,

I just fixed this issue in another plugin that wasn’t registering a hook with the wp cron action, and I think the issue in WP SEO not firing the wpseo_ping_search_engines cron job will be fixed in the same way.

We simply need to hook it in I think.

You’ll just need to add something like this:

add_action( ‘wpseo_ping_search_engines’, ‘wpseo_ping_search_engines’ );

That should register the hook and enable the cron job to fire as right now I don’t think it is when a new blog post is posted.

Let me know what you think.

Also just checked in my error_log to see these Joost:

[14-Jan-2013 16:11:18 UTC] PHP Parse error: syntax error, unexpected $end in /home/mysite/public_html/wp-content/plugins/wordpress-seo/inc/wpseo-functions.php on line 149

I think I may have been restoring a backup at the time though, so it may not be relevant.

Would love to get that cron job back working though!

No worries eplans, glad you got it fixed!

Esmi, I’m not sure if we should post hosts as those that are less pro-active in fixing this issue may be retargeted.

Perhaps when we know everyone has heard back from their hosts with what action has been taken and that any potential issue has been resolved.

People right now need to be setting their wp-config.php file to the permission 600 if possible and moving it up one level above the default directory.

That will stop anyone from reading DB passwords if they are hacked.

You too should do that eplan.

FTP into your install and right click your wp-config..php file, click on permissions and change it to 600.

See if the site still functions properly. If not use 640.

Then when it works, move your wp-config.php file up one directory into the root of your server.

If it all works and your blog functions leave it there, it will be much safer.