Dutch van Andel

In my php.ini I set allow_call_time_pass_reference = On and I’m still getting the blank white screen. Also, I’m running WordPress 3.1 and PHP 5.2.6.

The only other messages I’m getting are generic deprecated notices.

Notice: get_settings is deprecated since version 2.1! Use get_option() instead. in /path-to-site/httpdocs/wp-includes/functions.php on line 3303

Notice: get_settings is deprecated since version 2.1! Use get_option() instead. in /path-to-site/httpdocs/wp-includes/functions.php on line 3303

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in /path-to-site/httpdocs/wp-includes/functions.php on line 3303

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in /path-to-site/httpdocs/wp-includes/functions.php on line 3303

Maybe the querystring variables aren’t being properly registered with WordPress and are being lost/ignored?

I have the same issue. When WP debug is enabled, these are the errors I get…

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of call_user_func(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /path-to-site/httpdocs/wp-content/plugins/bc-oauth/lib/php-openid/Auth/OpenID/Consumer.php on line 1184

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of call_user_func(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /path-to-site/httpdocs/wp-content/plugins/bc-oauth/lib/php-openid/Auth/Yadis/Manager.php on line 416

I have a confession to make, I noticed this while making the last QA pass on 1.4 for custom post types and decided not to fix it (paid work is piling up and has to take precedence).

Theoretically, this is a very simple fix, so as soon as I get a bit of free time I’ll take a crack at it and push it out as a minor update.

Just so I understand, this is what you’re experiencing (?)…

You have some pages in your navigation menus, but when you protect those pages, they disappear. You want the pages to remain visible, even though they’re protected, so that you can prompt the user for a registration.

That’s definitely possible. Essentially, you just need to a) set up some custom WordPress menus and b) disable PSC’s menu filtering option. You need to use custom menus so that you can selectively choose what pages to display, and then disable menu filtering so that PSC won’t automatically hide anything for you.

Here’s more detailed instructions:

1. From your admin, go to Appearance > Menus and create a new Custom Menu. Create the menu exactly how you want it to appear.
2. Go to Settings > Page Security and uncheck the option for “Enable Menu Filtering”. With this option turned off, PSC will no longer hide protected content from menus.

This is definitely a scenario I’ve experienced myself and, while the above solution is a little roundabout, it works. The next update (1.5, not today’s 1.4 release) is going to include an overhaul of the Restrict Access sidebar – and “Allow in menus” is one of the new options on the todo list. Hopefully the custom menu workaround will do the trick in the mean time, though.

And thanks for the support. It means a lot! ??

You’re welcome!

BTW, the message link simply points back to the site root – so if you have a static page set as the homepage, and it’s protected, you would be redirected right back to that Access Denied page/message as if you didn’t go anywhere.

You can change the message from your admin section under Settings > Page Security. You can either set any custom plain message or select an existing page to use for your Access Denied message.

Ah, ok. At the moment it’s not possible since the blog page is a ‘special’ page type, that would need to be handled explicitly.

This seems like a straightforward feature though, so I’ll fast-track it to 1.4 (which is scheduled for Friday, if everything goes as planned).

If time is of the essence, you can protect posts individually for now and then turn on blog protection when 1.4 is released.

By ‘posting page’ do you mean the ‘blog page’?

Just to be clear – are you trying to protect the entire blog page (the page that shows all blog posts)?

Something odd is definitely going on as this (and the assigned groups issue) are not normal. Here’s what I’d try:

1) Deactive the plugin (don’t delete it – that will erase your settings)
2) MANUALLY delete the plugin directory from wp-content/plugins
3) Reinstall PSC using WordPress’s automated plugin search tools (dont do a manual install).

If there are any bizarre file-related issues, this should clear them up. If not, try this:

1) Open /wp-config.php (site root)
2) Change define('WP_DEBUG', false); to define('WP_DEBUG', true);
3) See if any error messages, notices, or warnings show up on the PSC pages.

Please let me know if either of these approaches yields results (either a fix or an error message).

One quick note for anyone stumbling on this, the above “fix” has scope resolution problems with WordPress.

IMPORTANT NOTES:
1. Only pass STATIC functions to hook callbacks (fixes scope problem) using the scope-resolution operator (::).
2. Use only string-formatted callbacks (fixes WP ‘expected callback’ problem).

The following is the only way to do this without running into problems (note that install() also had to be changed to a static function):

register_activation_hook(__FILE__, 'myClass::install' );

To answer my own question, I didn’t realize that you could use ANY PHP callback style. On a whim, I simply changed my register_activation_hook to:

register_activation_hook(__FILE__, $fpdb->install() );

Bingo. It works.

What do you mean by “removed the ‘registered user’ level access”?

Was it previously attached to certain pages (and you simply removed it from the page’s security settings) or did you modify the plugin to remove it altogether?

The group isn’t automatically added to anything, so I’m assuming you mean you had it previously attached to a few pages, and then removed it from their permissions?

If you can post a screenshot or two to clarify, it definitely would help.

??

I found the problem and it is now fixed.

Please update to 1.3.2.

Thanks for the heads up. I’m looking into it.