Jason Judge

Just FYI, one model I would like to implement is:

– Every WP user has one (or maybe more) MP account. The accounts are linked and the link is never broken.

– A user must register as a WP user to get a MP account (no MP accounts can exist without a linking WP account).

– A user logs into WP to get access to their MP settings (and if they have multiple MP accounts, get access to all of them).

This would mean that the subscribe form simply does not exist – a user would to go the “manage subscriptions” page to subscribe or unsubscribe. If they are not logged into WP when visiting that page, then they are invited to do so.

Is this possible?

There are other possible models that keep the MP users separate from the WP users. However, if the site allows registration for any other reason, then it makes sense to ensure the accounts are synchronised, otherwise it confuses the hell out of end users having more than one account on the website for different purposes.

— Jason

I think I am on the point of giving up on this plugin.

The back end is the best I have seen – the way it handles the e-mails, bounces, the way e-mails are sent out in batches and tracked etc. It just rocks.

The front end, however, seems to be full of traps, mostly revolving around this dual user system – one system for WP and one for MP. Synchronisation between the two is extremely easy to break, and very hard to join back up again. A single WP user can have many e-mails registered, but can only get back to the admin screen on the first of them.

Even when I am not logged into WP, MP seems to remember one of the subscribed MP users.

The front end seems to follow a model that is neither fully integrated with WP, nor the fully separate from WP. For example – even if I am logged into WP, with full user synchronisation enabled, I can subscribe to MP using a third e-mail address, and then go through the e-mail confirmation process. This ends up with multiple MP users semi-synchronised with the WP user, and no ability to select any particular one to manage.

With the documentation being sparse, it is difficult to tell whether the module is supposed to work like this or not.

Sorry if this comes across negative, but I have spend weeks trying to understand MP, but just don’t get the front end. Is it me? Quite possibly. Any tips before I give up? I really don’t want to lose that wonderful back-end functionality.

— Jason

I think I’m going the same way. The functionality looked perfect for my needs, but the problems it introduces in WP2.9 are just too much to work around. This plugin replies too heavily on the JavaScript of a much older version of WP, much of which has now changed.

The lack of updates or any contact from the author is a problem that makes it difficult to see a way through this (considering how complex the JavaScript is).

You cannot hang around with WP updates, since so many of them contain security updates that *must* be applied immediately they are released. It is up to the modules to keep up with WP – there is no other way it will work.

I just don’t see any other plugins that do the same thing.

— Jason

Just with a quick perusal of this plugin’s code, I can see the major problem: the global functions are not given a proper namespace prefix. Functions such as get_a_post(), gallery_styles() and startGallery(), and global variables such as $options_page are just asking to clash with every other gallery plugin out there.

The plugin also will not work if you have moved or renamed your content or admin directories, since there are a lot of hard-coded paths in the code.

The JS scripts could also do with loading through the appropriate APIs, which then allow overrides etc. especially if the site already has a mootools library loaded through the theme or another module.

Having said that, the code in this module is very short and simple, so it should be pretty easy to tidy up and fix these things.

— Jason

Even <img src="/wp-content/uploads/filename.jpg" /> is still absolute with respect to the domain.

Better would be to support relative URLs like <img src="wp-content/uploads/filename.jpg" />. That way a site can be developed in a folder and moved up to the root (or to another folder) when deployed.

This would require either an output filter that modifies these relative URLs depending upon the current page path, or the use of the “base” meta-tag to tell the browser to treat all relative paths wrt the site root.

I’m going through this myself at the moment, and am use to just being able to move a whole CMS, knowing that all links are relative, so this came as a surprise to me.

— Jason

I have not tested this with Role Scoper yet. Perhaps someone who tries it out could provide some feedback?

— Jason

I have not found any information on this plugin that is less than six months old. Does that mean it is a dead plugin? Or has development moved elsewhere?

— Jason

donncha – the SVN update worked. I had to merge it all with my own changes, but it looks good. Just FYI, one thing I changed was the namespace for the functions – I made sure they all had the same prefix on (mu_domain_mapping_) so there was less chance of clashing with other plugins.

If it is possible to put all these functions into a static class, I think that would help even more wrt namespaces. Of course, it may not be a problem to anyone like it is now, but I’m always aware how much work it can be to integrate PHP applications when function and variable names are not suitably prefixed to keep them out of each other’s way.

— Jason

Cool – will do.

There is something that I would like to be able to do with this plugin: I would like to be able to support, on a blog-by-blog basis, how the blog is accessed. This would include by unique domain, by sub-domain, or by path on specified domains. Having that flexibility would be great.

I believe it is technically possible, but I think there may be clashes if one site using a sub-domain happens to have a page with the same name as a blog using paths (e.g. blog1 has a page called ‘/blog2’ and blog2 uses the path ‘/blog2’ to identify itself. I guess so long as they are on different domains, it probably does not matter, but anyway, you get the idea. I’m just wondering whether that has already been done by anyone, or whether it is an idea that has been requested before?

Edit: maybe the options should be set on a domain-by-domain basis, rather than blog-by-blog?

Edit: Oh, and some other things I would like to do, is to declare some of the domains and paths as ‘preferred’ so that a redirect happens if any of the others are accessed, with perhaps a different preferred admin and non-admin domain. That way all the blogs could be administered from a single domain, using paths, so the administrator remains logged in to them all, while still providing public access through an alternate domain.

— Jason

I updated the ‘domain_mapping_siteurl()’ function in domain_mapping.php to try and solve this problem. TBH the queries will be well indexed anyway, but this change will save the results of the query so it does not need to be executed for every link generated on the page.

function domain_mapping_siteurl( $setting ) {
	global $wpdb, $current_blog;

	// To reduce the number of database queries, save the results the first time we encounter each blog ID.
	static $return_url = array();

	if (!isset($return_url[$wpdb->blogid])) {
		$s = $wpdb->suppress_errors();

		// Try matching on the current URL domain and blog first. This will take priorty.
		$dm_domain = $wpdb->escape( preg_replace( "/^www\./", "", $_SERVER[ 'HTTP_HOST' ] ) );
		$domain = $wpdb->get_var( "SELECT domain FROM {$wpdb->dmtable} WHERE domain = '{$dm_domain}' AND blog_id = '{$wpdb->blogid}' LIMIT 1" );

		// If no match, then try against the blog ID alone (which we get, without a 'preferred domain' setting,
		// will be a matter of luck.
		if (empty($domain)) {
			$domain = $wpdb->get_var( "SELECT domain FROM {$wpdb->dmtable} WHERE blog_id = '{$wpdb->blogid}'" );
		}

		$wpdb->suppress_errors( $s );
		$protocol = ( 'on' == strtolower($_SERVER['HTTPS']) ) ? 'https://' : 'https://';
		if ($domain) {
			$return_url[$wpdb->blogid] = untrailingslashit( $protocol . $domain . $current_blog->path );
			$setting = $return_url[$wpdb->blogid];
		} else {
			$return_url[$wpdb->blogid] = false;
		}
	} elseif ($return_url[$wpdb->blogid] !== FALSE) {
		$setting = $return_url[$wpdb->blogid];
	}

	return $setting;
}
add_action( 'pre_option_siteurl', 'domain_mapping_siteurl' );
add_action( 'pre_option_home', 'domain_mapping_siteurl' );

As a bonus, this also allows you to add several domains to a single blog and access the blog through any of those domains. Although you would not want to make all those domains public, it does help to still be able to access the blogs using their sub-domains, for the administration screens at least.