Tom Belknap

I’ve finally gotten the plugin working with GIT and SVN, so yes. There has been a recent update and will likely be another some time after the new year.

What you’re requesting would be easily done as it’s own plugin – perhaps as a fork of my repo – but it’s definitely not something I’d consider developing into the main plugin. All you’d want to do is instead of splitting the title up by spaces as I’ve done, split it up at the dash (-) symbol and process accordingly.

Hope that helps. Cheers!

Sorry! There’s no plans on making this work with bulk updates.

@studio – I think I’ve solved this on another thread. Disable remote login and “Redirect admin pages” and it’s working for me.

Wait. For some reason, disabling remote login seems to work. Unchecking the “Redirect administration pages to site’s original domain (remote login disabled if this redirect is disabled)” checkbox solved the problem.

I guess I thought those worked the other way? customdomain.com/wp-admin would work if those boxes were checked? Guess not..

Hey, Ron. Sorry I didn’t get back to this post. I’m experiencing even more weirdness.

Well, there have been numerous updates to the plugin and of course to WordPress. But in terms of my settings for Domain Mapping, I’ve not changed a thing. There have been some redirects setup for CPTs, but no major changes to my VirtualHost file (I keep those directives in VH rather than .htaccess).

Now when I setup a new blog with a custom domain, the homepage works fine, but all links off that page link back to dragonflyeye.net/thisblogsubdir/the-blog-post

Well, hurray and damnit. Because I’m not using .htaccess, but adding all my directives into the VirtualHost record, these settings didn’t carry over to the new site. Better, now.

Also, I’m able to access the same file here:
https://badassthursday.rocks/wp-content/blogs.dir/48/files/2014/11/punch-sm1.jpg

Thanks for the reply!

The weird thing about this is: this is not only not an account called “admin,” but in fact, is not an administrative account. It’s the limited account I use to post articles.

It is named after the domain name of the site. I guess I shall have to create a new account like you said and transfer articles over.

thanks again.

Huh. Interesting. I’ll have to try that when I get back to that machine. Thank you.

FF is the most recent version on Ubuntu. What the specific revision is, I don’t know.

Meaning WP_ALLOW_MULTISITE and MULTISITE. Yes, sir.

UPDATE OF AN UPDATE:

After digging up this article, I discovered the problem.

Just as with the above noted user meta table problem, there are values in the wp_options table that also refer to “wp_1,” including the wp_1_user_roles option, which lists out all capabilities on the site. Change that back to the correct wp_ format – that is: rename the option_name from “wp_1_user_roles” to “wp_user_roles” – and all is well. S’pose I’ll have to do the same with all the other values, too.

Hope anyone else searching finds this post helpful.

UPDATE: comparing to another multisite installation that I own, I noticed that there is a user meta value called wp_capabilities, which of course in my installation, is called wp_1_capabilities. I switched that meta key to the correct parlance and… no luck.

I’m assuming there must be a place in the database where the capabilities live, but I’m not seeing it?

Damn. Have the same issue.

I’m having the same issue, and for some reason, while I’ve unchecked the box for displaying with excerpts, it’s still right there.

The purpose is just to make sure there are always tags in posts. From my perspective, this meant making sure that whenever the post is saved, it is checked for tags. Thus, I’ve hooked onto the saving of posts.

If there’s more demand for it, I’d be happy to include an option to only tag on publish.