Subdirectories?

[Andrea_R]

Is the current code pretty stable with subdirectories? I know there was a time it was iffy, just checking for an idea I have.

Anything I need to look out for?

[Luke]

Working in sub-directory mode, or being installed in one?

I'll guess the first.

It's fairly stable, but not everything works with it. Some plugins and such have issues, etc.

[Andrea_R]

Yep, working in sub-dir mode.

Well, that's better than it was. I guess I'll find that out soon enough.

(and here I thought you'd say "no comment"...  )

[Luke]

Well, do a local install on Ron's machine. He isn't using it anyway since you keep him locked up in the basement.

Then test, test, and test.

Find out what works, doesn't work, and go from there.

Can't say I'm a big fan of sub-directory mode though.

One issue off the top of my head is with the site-wide feed, but that might not be the case anymore.

[Andrew]

Yeah, i'm not really a huge fan either. I don't typically code my plugins to work with subdirectories. Some of the premium plugins have it built in but that's about it.

Thanks,
Andrew

[Andrea_R]

Well, do a local install on Ron's machine. He isn't using it anyway since you keep him locked up in the basement.

Hey, someone's gotta work enough to pay the bills, of which there are plenty. Actually, his machine is... elsewhere.. but will be here ... soonish.

I have two ideas running for subdirs and neither is for a blog-farm type application, so we'll see how it goes.

Man, bending programs to do my will is addicting...

[Luke]

/me

I've been working in the rewrite rules area for a while now. Mainly in terms of rules for pages and such. They really add a load to the db, as Quenting pointed out on the MU forums a few weeks ago.

Most of which, IMHO, is unnecessary for pages.

Overall, I would definitely have to agree that coding for subdomains is more friendly.

[Andrew]

Are the rewrite rules any different for subdirectories? If so, are they also loaded into the db even if the site is suing subdomains?

Thanks,
Andrew

[Luke]

Not really.

When a rewrite rule is generated, it's generated.

All it does is translate what's in the browser (request_uri) to a dynamic value that WP can use.

for example, here's one of the rules in my db for my local test site:

Code:

s:11:"robots.txt$";
s:18:"index.php?robots=1";

Rules show up in pairs. First being what's called (robots.txt), and the second being what it maps to as a standard url (index.php?robots=1).

Rules are generated based on many things, obviously, but for me i would probably prefer to have a rewrite_rules table, where the rules are put into matched key/value pairs, vice being in one field and all serialized together.

Not that I'm going to say that Matt and Co. are out in left field on this, but that would make more sense to me logically, and would probably speed up the DB overall. Maybe not, but that's what makes sense to me. You know, that whole "load what you need" thing.

[ron_r]

Not that I'm going to say that Matt and Co. are out in left field on this, but that would make more sense to me logically, and would probably speed up the DB overall. Maybe not, but that's what makes sense to me. You know, that whole "load what you need" thing.

I would be up for trying this out, evaluating the performance thing.

[drmike]

Do note that some of the plugins (ie the mu feed) still appear not to work with subdirectories.

I wonder if the mu feed one pays attention to the $path variable.  Probably doesn't.

[Luke]

I'm not sure Doc, I couldn't say since I've never needed to worry about it.

[drmike]

I started with subdirectories since my first host wouldn't put in the wildcard.  I prefer the subdomians though as well.

[Luke]

I prefer them as well.

To me, it provides a little something "extra" that makes the end user feel "important". If that makes sense.

I mean, it isn't a big deal on the back end, but that user can feel "special" that now they kind of have their own domain, with their name first. To me, it seems better than domain.tld/name/.

Plus I just like the look better.

[Andrea_R]

I prefer them too, but I'm thinking of situations where people can't mess with wildcards or aren't allowed.

And I'm also seeing more communities where the username is a subdir, so I think the unwashed masses aren't minding much.

[Luke]

Which makes having their "own domain" even more special.

And really, if someone can't mess with wildcards then they're on the wrong host. But, we've been down that road far too many times.

[drmike]

That host went out of business.  They had issues.

[itdamager]

I updated the sitewide feed plugin a few days back to support subdirectory installs. Give it a whirl and see if works for you.

http://www.itdamager.com/plugins/wpmu-sitewide-feed/

[Luke]

Any other updates to it? Or just the subdirectory compatibility?

[itdamager]

That's it right now, but after looking it over, it does indeed need some changes.

When I originally wrote the plugin, wordpress was undergoing internal db changes and the my plugin actually accounts for both the before and after. I think that after a year, I can clean all the old stuff out and lighten it up alot.

Also, I think the real answer to the subdir vs. subdomain install lies somewhere in wp_rewrite, instead of the way I trigger the feed output now. So I will investigate this further. The update I just made is more or less a workaround to this.

The options need cleaned up, and made to work properly for both subdomain and subdir installs.

Finally, there is the issue with scalability. For instance, using this plugin on a large site could be a large performance hit. I read the sitewide TAG thread on the other forum and was intrigued at the 2nd wordpress install solution. Running a sitewide feed from a second wordpress install might eliminate that problem. Then you'd just have a tradeoff between a large wordpress db problem instead of a bazillion (exaggerated) queries from my plugin. I used a 'postmap' when I first wrote the plugin to keep track of updated posts, but it was tedious, and I couldn't measure much of a performance difference so I dropped it and used the built-in wordpress cache to keep the load down.

Any suggestions appreciated.

[drmike]

I read the sitewide TAG thread on the other forum and was intrigued at the 2nd wordpress install solution.

Well i do have my moments of genius sometimes.

Running a sitewide feed from a second wordpress install might eliminate that problem.

The problem with that though is we're using your sitewide feed plugin to get those posts into the second wp install.

The only other solutions I can think of, which just came to me, is to create a sitewide posts table, keep it set to how many posts you want it, (say 25) and just add in a post to that when one is written and drop off the oldest one if there's more than 25.

Hmm, that might be a better method for keeping sitewide tags as well.  Just have a table for each category and add and subtract off of those when a new post is created.  (I think that's what wp.com is doing.)

edit: Gotta admit though that due to the recent issue I've had with the Automattic staff and the existing "I want you to do this code for me and I'm demanding it" attitude that seems to come from the mu.wp.org forums, I'm not big on release wordpress code to the public currently.

[Luke]

I read the sitewide TAG thread on the other forum and was intrigued at the 2nd wordpress install solution.

Well i do have my moments of genius sometimes.

Yep, that you do Doc.

The only other solutions I can think of, which just came to me, is to create a sitewide posts table, keep it set to how many posts you want it, (say 25) and just add in a post to that when one is written and drop off the oldest one if there's more than 25.

I'm currently working on something similar, but on a smaller scale. It's keeping any post in a table for 24 hours, then the table is truncated, and the process repeats.

Gotta admit though that due to the recent issue I've had with the Automattic staff and the existing "I want you to do this code for me and I'm demanding it" attitude that seems to come from the mu.wp.org forums, I'm not big on release wordpress code to the public currently.

I'm not on the public side much either. I've got a couple minuscule plugins that I'll keep up with, but other than that I quit the whole sharing thing for that exact reason.

It sucks that it pretty much has come down to it, but I'd rather share it amongst a few friends who appreciate it.

To me, I guess the only downside of a sitewide feed is that on an active site, it can really miss a lot. ITD's right though, on a really big site it could eat up quite a lot. There has to be a logical solution to both a sitewide feed, and tags as well. Problem being, how much do you want to eat. It's going to eat something, but how much is the question.

For example, with Doc's off the cuff idea about tags, can you imagine how many tables that would create Doc? It could really get big, quick.

To be continued...

[Andrea_R]

If we're talking a large enough site for it to be a problem ,would multidbs come in and if so, why not just stuff it off in its own db?

[drmike]

If we're talking a large enough site for it to be a problem ,would multidbs come in and if so, why not just stuff it off in its own db?

That was my idea.  Add in calls with the create and delete posts occurances and drop the data into it's own db.

Not sure why Luke only wants to do it for 24 hours though.  Seems awefully short.

[Luke]

Because it would be for something else, before this discussion came up.

[drmike]

Oh, ok.  I'm used to seeing "Posted one year ago..." over in wp.com land.

[Luke]

I was looking at "hot posts of the day", which is where 24 hours came from.

[drmike]

On the front of wp.com or the tag pages?

[Luke]

For my own personal use, on whichever page it fits.