[Plugin: More Privacy Options] Doesn’t work

Ha, oops, sorry, my bad. There is a spot of code that has been deprecated … $user_level.

So, I’ve replaced the $user_level checks with is_user_logged_in() instead and it appears to work fine once again.

I’ve uploaded the update.

@ David

latest version of More Privacy Options on WP 3.0.1 multi site, installed in mu-plugins etc as per instructions … but with WP_DEBUG true in wp_config ….

Setting privacy to Admins only with debug true displays (obfuscating identifying info) on the wp-admin or wp-login form

Notice: Use of undefined constant name - assumed 'name' in /home/serveruser/public_html/domain-folder/wp-content/mu-plugins/ds_wp3_private_blog.php on line 386
sitename can be viewed by administrators only.

Setting super-admin options to community members only also brings up a second, similar, warning for that privacy condition as well.

Thought you should know, because with WP_DEBUG = true, it reveals server user and path name on the blocker login screen to any old Tom Dick or Harry that finds your domain name.

Thanks, gazouteast

Do not enable WP_DEBUG = true on a your live site for every Tom Dick or Harry to see your debugging errors/warnings/notices.

bloginfo(name) with no quotes creates the notice but passes the correct value so I never noticed the typo, where bloginfo(‘name’) fixes the bug.

Installed plug-in. Activated it for one site only, on a multi-site install of WP.
logged out.
logged back in as a subscriber.

2 problems.

1) after login user ends up at dashboard, not blog
2) going to blog, always ends up back at dashboard.

What could be wrong?

~ thanks

This plugin was previously working well for us but in the upgrade to WP 3 something has gone awry and we only see the basic (entirely public) privacy options. Is there a known conflict with blogs that moved from WPMU 2 to WP 3?

I could be wrong Nicola, as I didn’t have that issue myself, but it’s possible all the new (extra) action hooks in WP 3+ need this particular plugin to be deactivated, then reactivated after upgrading core.

I viewed it as one of the ones that should be inactive during the upgrade because of its effect on user permissions, so that’s what I did, and maybe why it gave me no problem between versions.

No doubt David will be along soon and give you the correct answer ??

That’s helpful – I shall keep an eye out for something from David but thanks for the heads up Gaouteast ??

@nicolaosborne I would normally deactivate all plugins when upgrading, including “mu-plugins” – especially in the case of the major upgrade from WPMU2.9.2 to WP3.x.

Tracking down updates to “mu-plugins” must be done manually as mu-plugins don’t trigger the “phone home” to the WordPress repository. Conversely, tracking down the plugin through the blogs Plugin->Install will erroneously install the plugin into the normal plugins directory instead of the mu-plugins. You’ll need to manually move it over so it is active. Further, you might end up with an old version in the mu-plugins and an update in the plugins that collide and cause even bigger headaches. MAke sure you have the correct plugin version installed in the correct folder.

@nicolaosborne, and @carterbrooks I am unable to reproduce the problems you describe with the info you’ve provided. I have WP3.01(multisite) and version 3.0.1.3 of the More Privacy Options “mu-plugin” installed.

@dsader Wondering if you have any light what problems might have been created by trying to install a WP3.0-incompatible plug-in on a WP3.0 install. Is it possible that activating the plugin made changes to core WP files that I need to reinstall? Or setting in the mySQL database? Just a newbie, so not sure where I should be best looking to track down the file. Thanks for any ideas.

@carterbrooks it is not possible for [Plugin: More Privacy Options] to change core files or alter the behaviour of the db in any way.

General advice: If you start from scratch again, record notes of what you do in what order to reproduce the bugs you see. When(before) you install plugins, pay close attention to what files/folders are intalled – double -triple-check the details of a plugin before installation. Read the description/installation/faq/notes all before clicking the install button.

@dsader Thanks. I did get it working. Seems to have something to do with the Domain mapping. I am using a host where it is not possible to use the subdomain method for multi-site. Consequently all the domain mapping his handled through the domain-mapping plug in… etc.

Anyway, I found that I had to change the individual database options to get to work. If I am mapping the blog to a subdomain, or different domain than the main network, then it seems to be essential that the site options database has the subomain/alternate domain urls in the home and site url fields. Just setting the domain to “primary domain” in the domain mapping doesn’t seem to work.

Same issue if using the “Private! WordPress Access Control” plug-in.

Hi. I’m having an issue too when trying to make a blog viewable to a specific group. They’re all public. Any resolution to this? using 3.1 and latest plugin.

Hi David – just a thought regarding mu-plugins not checking for updated versions … would there be any issue caused by having the active plugin in “mu-plugins”, but an inactive same-version in “plugins” listening for an update notice?

Could be a workaround until core devs release a system for mu-plugins to phone home?

edit: I must proof read for typos before submitting posts.

Have loaded this and all appears great EXCEPT for the strange login redirect to the dashboard page. Can you please explain to a complete newbie what I need to put into the mu-plugins php file to redirect to the site’s homepage?

@gazouteast I never tried. A “sandbox install” on a non-live site with all such mu-plugins inactive in the plugins folder may be a workaround that is a little safer than having 2 copies of the same plugin in the same live install.

@seth I haven’t tested the plugin with WP3.1. I haven’t upgraded to WP3.0.2 yet. Review the installation instructions for this plugin with WP3.0.1. I can’t reproduce an error with what you’ve written.

@s-newbie “EXCEPT for the strange login redirect to the dashboard page”. Where do your logins redirect without this plugin? This plugin by itself doesn’t alter the behavior of the normal login redirects.

The following code in a php file in the mu-plugins folder will redirect successful logins back to the page that was requested:

<?php
function ds_my_login_page_redirect() {
    $redirect = urlencode( $_SERVER['REQUEST_URI'] );
    $page = get_option( 'siteurl' ) . '/wp-login.php?redirect_to=' . $redirect;
    return $page;
}
add_filter( 'login_url', 'ds_my_login_page_redirect' );
?>