plugins_lexblog

This error also appears for me after updating to v2.1 (the %%tag%% variable also throws the same warning), but it appears that the setting still carries through to where it is being used on the site(s). Is there a plan to address this or are these variables going to be deprecated at some point?

Actually, there are a few more similar errors, all around checking for isset:

Undefined index: category_name

Undefined index: s

Undefined index: tag

You can “fix” this by editing the following in admin/pages/xml-sitemaps.php:

You are referring to code within the Yoast plugin there, correct?

Just to be clear, I’m not claiming there is a fatal error, just that the sitemap fails google validation.

It seems to me that the “author” taxonomy in your plugin would conflict with Yoast’s attempt to generate an “author” sitemap — his plugin is referencing “author” as in, standard wordpress user, not your taxonomy term.

EDIT: The reason I say that is because “author” is a valid permalink component and valid parameter for the wp_query. How would other plugins know which “author” a given url string is referring to?

But for clarity’s sake, I will snoop around in debug mode and see what I see.

Thanks very much for your comments.

That sitemap is generated by the Yoast SEO plugin.

Tomorrow I’ll write a little test script to see what taxonomies are registered but, I mean, isn’t there an author taxonomy being registered at like 142 of your plugin?

Ron-

thanks for your thoughtful reply. I’m the developer who will be looking into the custom code to handle this issue. Would the code you envision to handle this selective enablement be something along the lines of case switches for each of the domains? Any offhand guidance is appreciated since changes to this file seems to be in the category of a core change to my thinking.

Answer provided through wp touch pro support.

Very good question.

1) We use the same parent theme across hundreds of blogs, so we try to avoid adding code that will only apply to any small subset of them (which this would, in our case).

2) We try to avoid making any changes at all to the parent theme because we are in a very demanding vertical and it’s not feasible to test code changes to the parent theme across all our blogs.

3) It would be tedious to remember to add this in the child theme of every blog that needs it.

4) We could just write another plugin to include this as necessary, but it will be difficult to remember to activate our plugin every time we activate your plugin.

5) We’re already running a ton of plugins that are network activated. We’re trying to cut back as it is, so network activating this AND our patch is not an option.

6) It’s a good update! Maybe include it as a conditional based on an option in the management page?

Awesome, thank you. I ended up adding a modified part of that snippet to line 280 of your plugin:

if ( username_exists( $userdata['user_login'] ) || email_exists( $userdata['user_email'] ) ) {
        		if ( $userdata['user_login'] ) {
          			$user = get_user_by( 'login', $userdata['user_login'] );
        		} else {
          			$user = get_user_by( 'email', $userdata['user_email'] );
				}
        		$user_id = add_user_to_blog( get_current_blog_id(), $user->ID, $userdata['role'] );

		        $userdata['ID'] = $user->ID;

      		}

Obviously, that’s going to bite the dust whenever we update your plugin. Would you consider integrating this, or something similar, into your plugin?

Here’s a clarification of my setup and the reasons:

https://www.site1.com => URL the world sees when they go to the site

site1.company.com => company.com has a wildcard SSL certificate attached to it because the client has many sites, so the wildcard cert is the most cost efficient way to give them SSL access across all their site backends at site2.company.com and site3.company.com

Most of the client’s sites use sitename.company.com, but three of them are different (site4.com, site5.com, site6.com)

So you’re saying I will need to modify the code to make this work? My thoughts are to possibly put a wrapper around the whole domain mapping plugin…

if($SERVER[‘HTTP_HOST’] == ‘company.com’)
{
… bypass the domain mapping plugin somehow based on the URI
}
else
{
… run the domain mapping code as intended …
}

Hi Ron –

Thanks for your reply!

I am not using SSL for the primary domain – only for the sub-domain (non-primary) backend part of the site.

Any other ideas?

Thank you for the response, Ulrich.

I guess I was thinking about something more like,

https://codex.www.ads-software.com/Function_Reference/username_exists

https://codex.www.ads-software.com/Function_Reference/email_exists

if(username_exists() || email_exists()) {
    just add the guy to this blog and log this in the log.
}

Does that make sense? I saw the function you pasted in the other thread, but I didn’t see how that would apply here.

We are having the same issue. We’re on Apache and we have the most current version of this plugin. It’s still redirecting when we try and login via the admin between the domain and sub-domain and the login fails. So if a fix was leveraged, it’s not working with the most recent version of Domain Mapping on 3.4.2.

The theory there is pretty common: A lot of blogs might have a page called “Privacy Policy”. So, consider if it’s a legal blog about IP Law & Privacy: That page is not relative to most searches.

IMO that snippet is poorly executed though and should sniff for is_admin and is_main_query. We take it a step further and specifically exclude such pages by slug instead of post_type.

Lol, I wouldn’t exactly say my life is a nightmare, at least not because of wordpress debug messages. It would be a good practice to fix this though.