boxcarpress

I suppose it’s possible to filter the WP Query to inject your WHERE clause but this would be a bad idea. This problem is better avoided altogether by creating new taxonomies for users. In other words, do this:

register_taxonomy('mytaxonomy','post', $args);
register_taxonomy('user_mytaxonomy','user', $args);

NOT:

register_taxonomy('mytaxonomy',array('post','user), $args);

On second look, I don’t think that it’s a good idea to have a taxonomy apply to both posts and users (as I explain how to do in the first post). See: https://www.ads-software.com/support/topic/dont-share-taxonomies-between-users-and-posts?replies=1#post-4921419

I don’t think it’s a good idea to share taxonomies between posts and users. See: https://www.ads-software.com/support/topic/dont-share-taxonomies-between-users-and-posts?replies=1#post-4921419

Note that the new version 1.3 of this plugin DOES NOT have this 8 month old fix applied. I had mistakenly believed that one of the comments in the changelog meant this was corrected in the plugin code, but this is not the case. You will have to apply these patches again with version 1.3.

If the new plugin developer is listening, is this code available on github so that community members could apply the patch to help avoid this regression again?

Great news! Thanks for the update.

I guess the plugin supports WP 2.6 or higher and the home_url() function only appears in 3.0 or later. So, this patch won’t work if you are pre-3.0.

This has the side effect of interfering with valid query strings within the URL. So the URL:
https://www.example.com/blog/?sandwich=ham-and-cheese
…shows up with the $_REQUEST variables:
array(2) { ["/blog/?sandwich"]=> string(14) "ham-and-cheese" ["sandwich"]=> string(14) "ham-and-cheese" }
…instead of:
array(1) { ["sandwich"]=> string(14) "ham-and-cheese" }

More concerning is that the $_SERVER[‘REQUEST_URI’] has now become ‘https://www.example.com/blog/?sandwich’

I think I’ve followed your configuration example from earlier in this thread but it’s possible I have something misconfigured. That said, the method I describe (where I don’t include the $request_uri at all in the rewrite) appeared to work without any side effects. Could you explain the reason that you need to include the $request_uri in the configuration at all?

Thanks for the terrific plugin. It’s speedy!

I would vote for:

• Exclude caching by URL and/or by post_type
• Save the settings to the DB so that deactivating doesn’t wipe them out

I too was experiencing 404 errors throughout my WP 3.5.1 multisite blog. FWIW I use the nginx Helper and set up conf files pretty much exactly how you set them up, Peter. I was finally able to get this working by adjusting the nginx.conf file as follows (modified from the example above):

location @memcached {
# ...snip....see code from Peter's example above above...

      		if ( $memcached_request = 1) {
			# I added this to help debugging. It means a cache "hit"
			# (meaning you have bypassed PHP/WP entirely) :
       			add_header X-Cache-Engine "WP-FFPC";

			memcached_pass memcached-servers;
       			error_page 404 = @rewrites;
      		}

		if ( $memcached_request = 0) {
			# before:
			# rewrite ^ /index.php$request_uri last;
			# after:
			rewrite ^ /index.php last;
		}
	}

	## rewrite rules
	location @rewrites {
		# before:
		# rewrite ^ /index.php$request_uri last;
		# after:
		rewrite ^ /index.php last;
	}

During debugging the configuration (perhaps it’s obvious but I kept forgetting so I’ll mention), first:
1) purge the cache and
2) disable the plugin entirely.
This will keep the cached pages (that live on after the plugin is deactivated) from affecting your results.

If you recently installed or re-installed the Nginx Helper you may need to also adjust your Settings>Permalinks to remove the index.php.

I hope this helps. Let me know if you need any other information on my setup.

It took me some time to figure out why this option was disabled. It appears you also need (first) to uncheck “Use single network configuration file for all sites.” Under General Setting>Miscellaneous

While we’re at it, here’s a fix to better handle the POST ajax call when you add a user taxonomy (so the code expects a $_REQUEST rather than a $_GET variable):
https://pastie.org/6464544

I’m still making this change manually for every update. Since there doesn’t appear to be any drawback to using get_object_taxonomies() instead of get_taxonomies(), I wonder if you could commit this change to avoid the strange behavior for others?

Finally was able to fix this. Don’t ask me why, but my problem is solved by a slight change to line 1444 of peters_collaborations_emails.php. I use get_object_taxonomies:
$taxonomies = get_object_taxonomies( $post_type, 'objects' );
…instead of using get_taxonomies(). The same code applies to line 1528:
$post_type_taxonomies = get_object_taxonomies( $post_type, 'names' );
This bug was frustrating because the code worked on our development server but not on our production server. We replicate the DB and have the same codebase, so I really can’t tell you why this would be the case. One (slight) difference is the PHP version, 5.4.9 in development and 5.4.6 in production. But anyway, I hope this helps.

I’ll admit that I don’t fully understand the Guest Author content, but I have a few followup points from someone blindsided by this behavior…

I don’t know who clicked “Create Profile,” but perhaps the label for this link could be more descriptive. “Set up as Guest Author”? It’s very enticing to click as is. Had I noticed it, I would have clicked on it to see what that was, just out of curiosity. So, afterwards, it’s not very clear that (by being curious) you have just now created a Guest Author. I clicked it now, and got a cryptic screen asking for “Related Guest-author 1”. When I navigate away, it’s unclear that I’ve done anything permanent to the User. I feel like I should have had to confirm or hit a save button before the plugin inserted the Guest Author into the database.

I am using WP in multisite, so I’m happy that you support multisite. But in the situation that you describe, the User already existed on this blog. In fact, she was an Editor and had lots of content that got mis-assigned to a random incorrect blog user on the frontend.

So, I don’t think it was clear that we were overriding an editor’s profile with a feature called “Guest Authors.” I wish that there were prompts, explanations, or confirmations along the way which allowed us to avoid this mistake. Since there are other that use get_coauthors() or CoAuthorsIterator to find information on their authors, I imagine this issue will continue to pop up. The fact that this sometimes returns a Guest Author’s post, from which we get an incorrect avatar and incorrect permalink, was unexpected. (On that note, perhaps you should have introduced a new function which behaves this way instead of changing the returned values of the existing function.)

Ok just some thoughts. Thanks for considering this issue, and in the meantime I’ll add the filter as you suggest.

If I understand the sales pitch, isn’t the WPMU Dev Domain Mapping able to accomplish this, though? Not that I would pay the mountly fee for that plugin, but is their implementation unsafe/insecure? I too would like this feature, but would love to understand the security implications further.