inge12

Thanks, Tim, it worked.

Should have thought of it myself.

But now I’m meeting strange behavior once more:
This install is in the root (/public_html/) directory.
The last time I installed a blog in the root, it automatically added /blog/ in the permalink structure, quite contrary to my expectations.
Then I was told that this is default behavior, and, indeed, the codex says that it is.

Now for the strange part:
In this install, WP is choosing not to insert the /blog/ into the permalink structure!

These permalinks currently work:
https://4goodhealth.com/category/lesson-helps/2011b-garments-of-grace/ (post)
https://4goodhealth.com/study-guides/ (page)

What gives?

Is WP just temperamental?

I want to understand what’s going on so that the next time I have to move a real site (coming up), I don’t pull out as much hair as the last time;)

Thanks much for the feedback. ??

PS Network functions seem to work. I have one sub-site installed.
I woulcn’t mind if this permalink structure were default behavior, but that is not how the real site is working! (I copied it to this domain for a sandbox environment.)

To answer my own question, I think “Multisite User Management” is it.

I shall see …

Yup. This does precisely what I want. ??

At first it seems there’s no change in the Network “Settings” page. That’s because the new options are at the very bottom of the page.

I’m familiar with HTML framesets, and I’m converting a static site to WordPress.

However, when I put the frameset code into the HTML code in my blog, I only get a blank.

I’m using WordPress 3.1.3 and the Weaver 2.0 theme.

I want to frame a subscription form for an email list that’s on a different domain/server.

Is that possible?

Maybe there’s a different way to do the same thing? (Sorry, I’m not tech-savvy)

Re Andrea’s suggestion:

Go to network admin. Install a plugin. Do not activate it.

Go to a sub site. See the newly installed plugin in the list. Activate it.

That’s the way I thought it should work. But it doesn’t — at least not without a plugin to create this behavior.

On a plain-vanilla multi-site, plugins not network-activated will not show at all in the subsites, as Steve@BGQ discovered.

Besides the ones Andrea mentioned, another plugin to extend management capabilities for sub-sites appears to be this one:
https://www.ads-software.com/extend/plugins/yd-wpmu-sitewide-options/

For more, search the plugin directory for “network plugins.” It seems there’s a plugin for almost any desired behavior.

To answer my own question:

One Method (what I did)
Download the database and make whatever edits are necessary for the new domain. Upload database to new site. It will not affect the normal operation of the site.

Copy the whole WordPress install to computer. Then upload whole WP install to new location — except for the index.php in the root directory. The original site will continue functioning as long as the WP index.php is not active. It is possible to log in to the moved WordPress install through URLofnewsite.com/wp-admin/ and make any edits/changes necessary, except that the “page preview” will not work. Through this login, it’s possible to create new posts (Welcome message, etc.), new pages, and whatever else is necessary.

When ready for the “big day”/launch time, install index.php and the blog will go live.

An easier way might be this:
Install WordPress on new site. Rename index.php, so it does not interfere with operation of site while preparing blog to go live.

Use plugin https://www.ads-software.com/extend/plugins/wordpress-importer/ to import everything from old site, except theme.

Since the import plugin does not import the theme, you will have to activate the theme you want to use — whether the same as the original site or note. (May have to tweak theme manually.

That looks a lot easier than what I did (following instructions found here and there).

Thanks to both of you. ??

Sounds great. ??
Thanks much!

Thanks much, Andrea! ??

Yes, indeed! That’s what I would like to see too.

Hi Ipstenu,
Yes, I read both Otto’s and Yoast’s explanation, and after reading Yoast’s explanation, I figured that just the postname should be fine. But then I noticed the WordPress warning and I read someone’s experience of noticeably slow response time after the database got bigger, causing that person to change the links to a numerically-based structure. So I changed back to year/month/postname — before the blog went live. Some of the posts will be date-sensitive anyway, so that’s fine.

On another multi-site installation I’m planning (hope I won’t need help on that one!), I will change the structure to /postID/postname because the material is not date-sensitive, and I don’t want older posts to look “old” right in the address bar. ??

When I get there, I may need some help on what to do to ensure that old in-links will still work. Or I’ll have to design a very helpful and appealing 404 error page. ??

As for the “/blog/” — I did force it out — through editing the database, thinking it was just a holdover from the blog sub-directory install. And, as you said, by switching permalink structure back and forth, the “/blog/” came back.

I’m tech-ignorant enough that I’d best stay with the best-supported methods anyway. ?? That said, I did learn a lot through days of frustration in poring through the database — both in text format and through MyPHP. Trouble is that I’m likely to forget it soon, concentrating on blog content, rather than technicalities. ??

Oh, well, when I forget, I’ll just come back here, because you remember, seeing you deal with this stuff all the time. ??

Sure am glad you’re patrolling these forums. ?? Thanks again. ??

Thanks, Ipstenu. I must have screwed up something in the database via manual editing, and the actual permalinks didn’t use the /blog.

That was fixed by changing permalink structure back and forth.

Then, after some research, I discovered that just the post name would dramatically decrease performance when the site has more posts. So I changed to the /blog/year/month/postname structure.

Thanks again!

I think it’s all working now!!

H’mm …anyone have thoughts on this one?

I’m interested too.

OOPS! The editing was NOT in the .htaccess file but in the wp-config.php file!
That editing was necessary, as well as editing the database. There are probably other ways to do it, but this worked for me.

I changed the .htaccess file:
from
define( 'DOMAIN_CURRENT_SITE', 'blog.domain.net' );
to
define( 'DOMAIN_CURRENT_SITE', 'domain.net' );
but things still weren’t working.

Then I looked at the database through PHPAdmin and found that the domain for the blog was still specified as ‘blog.domain.net’

I edited the database directly to specify the domain as ‘domain.net’
Then things started working — i.e. the blog recognized the database.

I couldn’t figure out why it couldn’t find the blog, because all t he tables looked fine, until I looked at actual entries.

Things are working okay, but I’m beginning to think I’d rather not have too may sub-sites on this particular project. The current WordPress works just great for multiple authors, with queries pulling up archives for each one.

Otoh, it will save me some time on several of my personal sites.