Haven’t read it through myself either, just glanced it and figured there’s a lot of data there. They say some of it isn’t accurate though, or that it misrepresents some issues.

This looks related to a test case I was preparing to demonstrate how flawed the output from wpautop can get inside lists:

<ol>
<li>
foo

bar
</li>
</ol>

renders as:

<ol> 
<li> 
foo</p> 
<p>bar
</li> 
</ol>

whereas I’d expect it to be

<ol> 
<li> 
<p>foo</p> 
<p>bar</p>
</li> 
</ol>

I’m changing the summary to generally cover wpautop’s problems within <li> elements.

Sloth.

Apparently either results.php or head.php (in view/admin/) refers to an image called small.gif by a path that doesn’t work: every time I use Search Regex I get 404 hits for a ’/images/small.gif’, when it should in fact refer to [site root]/wp-content/plugins/search-regex/images/small.gif. Apparently $this->url() precluding the path in the code doesn’t work — maybe $this is out of scope?

Np, @RavanH, glad my contribution turned out so helpful!

Here’s a related link I just came across that you might find interesting: Aselain hiplaajat (in Finnish).

On a hunch, I instead opted to change Upload Url Path (of the main site) to point to where Fileupload Url already was pointing, and lo and behold, now the uploads get url’s with a /files/ base (which I feel is best).

Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base (like I mentioned in the previous comment), as if Upload Url Path didn’t have an effect. There doesn’t seem to be a Fileupload Url setting there — perhaps it’s deprecated? (The testing site runs trunk, whereas the main site runs latest stable.)

(Usually it’s the other way round: something that works in testing won’t work on the production site.)

I’m chiming in with my experience just in case more reproducers are of any help. I’ve encountered the issue @RavanH described in the initial post on my multisite install: files uploaded onto the root blog get url’s with blogs.dir while subsites (in subdirectories) get url’s without it.

I was running WPMU just prior to it getting integrated into WP proper, but unfortunately I can’t say for sure whether I did a clean reinstall or an upgrade to WP (non-MU) at that point.

I’m only running a single network with none of the plugins mentioned in this thread thus far. Well, no, actually I do run another multisite for testing purposes, completely separate from the first, and there this issue doesn’t manifest.

The upload-related variables for the main site are as follows:

`Upload Url Path:
Upload Path: wp-content/blogs.dir/1/files
Fileupload Url: http://mummila.net/files`

I suspect the Upload Path is what’s causing this; further evidence is that on the testing site Upload Path: wp-content/uploads results in url’s withoutblogs.dir.

I’m thinking of changing Upload Path, but I’m unsure where it ultimately shouldpoint to. If wp-content/uploads results in corresponding url’s, is that the default for the root blog? If so, is there a reason why it deviates from what the sub-sites have, which is sitepath/files? I’d expect the root site to have /files/ as attachment url base.

Ns. liian pitkät G+ muistaakseni lyhentää siinä uutisvirrassa oletuksena, siis että näyttää tiiserin jonka voi laajentaa. Eli pitäisi voida postata pitkiäkin löpinöitä murehtimatta toisten näkymän täyttymistä.

Hoo, vähänkö koleeta käyttää plusnotaatiota Plusan ulkopuolella!