Multisites?

@john,

I appreciate the offer, I’m hopefully onto something at the moment but I need to edit my code on my test MU site at home tonight and give it some testing. If that fails I may well need you help and offer of access to your site – bear with me for a couple of days.

@john,

Okay an update for you.

If a new user is created on a Multisite install with Subscribe2 activated but Join My Multisite is disabled the user, once the confirmation is clicked gets the following usermeta keys created:
admin_color
comment_shortcuts
description
first_name
last_name
nickname
rich_editing
show_admin_bar_front
use_ssl

However if Join My Multisite is enabled the user gets more keys created as follows:
admin_color
comment_shortcuts
description
first_name
imax_mu_capabilities
imax_mu_user_level
last_name
nickname
primary_blog
rich_editing
show_admin_bar_front
source_domain
use_ssl

It is the creation of these 3 extra keys that make Subscribe2 think that access should be granted to the Your Subscriptions menu.

The issues arise in the creation of the Subscribe2 keys at the same time because WordPress does not activate my code on a network level because Subscribe2 is designed to operate and be activated at site level.

I currently cannot hook into the user registration process at the time of activation because of this, but it does seem to be by design in WordPress and Join My Multisite changes this default behaviour.

So, my conclusion is that this is a plugin compatibility glitch producing an unexpected outcome. Fixing it is not going to be straightforward as the use of the existing hooks won’t work.

@john,

Speaking with Mika isn’t going to help. The issue you are experiencing is due to limitations of WordPress, “Join my Multisite” operating at network level and Subscribe2 operating at site level.

It is not really right that Subscribe2 tries to fix expected behavior of “Join my Multisite” nor that “Join my Multisite” tries to fix the expected behaviour of Subscribe2.

The only approaches I can think of are checking for the database entries when the Your Subscriptions is loaded but then this require the page to be loaded by the end user so it isn’t automatic. Or to create an entirely new plugin that would periodically check for users that need the database entries created.

There isn’t a quick and easy fix, at least not one that I can think of.

@john,

Yes, I did and I’ve just checked it again.

If I register a new user on a Multisite install that has only got Subscribe2 active (and not Join My Multisite) when that user is logged in there is no link to the Your Subscriptions page in the admin area of WordPress. If I am logged in and visit a multisite blog with the WordPress widget placed in the sidebar the link invites me to “Subscribe to email notifications when this blog posts new content”.

@john,

I don’t know what your question means, it makes no sense to me. In WordPress multisite testing site all registrations are all handled at the root domain/wp-signup.php, you cannot register at an individual blog.

@john,

Are you network registering the user and then from that same set of menus attaching that user to a blog? If so you are essentially manually doing what Join My Multisite does and that’s why it isn’t working.

You need to add users on each sub-blog, not from the Network menus.

@john,

I thought I explained this several times before.

Not clearly – are you talking about self registration or are you logged in and registering new users? I cannot replicate what you are seeing when I follow the steps you outline above, instead I get this:

– there is a multisite at http://www.domain.com/subdomain/ and other sites at http://www.domain.com/subdomain/sites (Join my Multisite is NOT installed)
– I’m a new user and I register at http://www.domain.com/wp-signup.php
– I get access and I have a Dashboard where the Subscribe2 menu does not appear.

If I cannot reproduce what you see I cannot work on looking at a cause.

In this comment here you seem to say you have enabled per-site registrations in “Join my Multisite”.

I stated here in the second paragraph that per-site settings remain persistent even if eventually unchecked. I needed to manually clear some database keys to restore normal behaviour.