salientdigital

Woohoo! Ipstenu, you’re my hero. I had no idea that was there, and never scrolled down far enough on the Network Settings page.

Now I get it. For anyone reading this in the future, as Ipstenu pointed out, there are two controls affecting the max upload filesize (in addition to the value in php.ini). What is reported to your WP Multisite domain’s Add Media screen is actually the smallest of these three values:

1) Your max_upload_filesize setting in php.ini;
2) how much actual space is left over when calculating [Site upload space] – [sum total of files already uploaded]
3) The max upload filesize value you set in wp-admin/network/settings.php

So in my case, with the meager default settings, all that was left after subtracting all the smaller images and stuff they already upload was 439kb. I can see this being really useful, for example, in assigning 100mb of storage to each of 10 domains in a 1GB hosting plan.

I haven’t changed any WP defaults, no. Based on almost every other post online, the main way people alter the max_upload_filesize is by hacking either php_flag in .htaccess (worst way) or custom php.ini in various folders under the WP install (also a bad way). These recommendations are things to try if you can’t edit php.ini. The thing is, I’ve edited my php.ini so I’m at a loss to explain how WP could be getting a setting of 439kb.

Where would I find this upload limit?

Yeah – weird. After restarting Apache it worked fine :-/

Interesting… from the thread on that bug report, dd32 said:

Whitespace immediately following a ?> is ignored by PHP and not rendered, However, Multiple new lines are not ignored (Single is fine, multiple is not).

I wonder where that information comes from.

Anyway I just set up a test with 3 simple PHP files and verified this is indeed the case on 5.3.6 however I am surprised that the WP Core devs wouldn’t want the cleanest code to the highest standard possible.

Thanks to this QA on Stack overflow, I figured out what I was missing before.

If you look up the thread at my original code, I didn’t realize that mod_rewrite actually doesn’t see the query string at all. It only cares about the document itself. If you need to analyze the query string to make your rewrite rule function you need a RewriteCond that looks at the %{QUERY_STRING} variable.

I’m posting the solution here in case it helps someone in the future.

In a nutshell, what wasn’t working for me were any URLs containing query string parameters. What I discovered is that it is possible to strip them out of the redirected page:

# in .htaccess, ABOVE WP and Multisite rules

Redirect 301 /foo /bar

This works – sends a 301 and relocates to /bar
Any url without query string parameters works fine this way.

# in .htaccess, ABOVE WP and Multisite rules

RewriteCond %{QUERY_STRING} ^var=val$ [NC]
RewriteRule (.*) /var/val? [L,R=301]

This works too – it sends a 301 and relocates to /var/val Note the ? after val in the rewrite rule? This little magic strips ?var=val from the resulting url. In other words, without the trailing question mark, the URL that gets redirected to is /var/val?var=val. By default, Apache tries to preserve the incoming query string parameters and pass them on to the redirected page, which, in my case, I didn’t want.

Problem solved.

Yep, I’m using the Apache & PHP that ship from Apple on a brand new Mac Mini, and MySQL 5.1 on a dev server on our LAN. A colleage uses MAMP Pro on a dual G5 and has verified all the same strangeness on his local box. And I’ve also replicated the same strangeness on my MBP 17″ under Snow Leopard. And the same thing happens on our staging server running Ubuntu 10.04 LTS.

Yes, I’m using Domain Mapper. I’m using the actual domain names in my hosts file to be able to use an identical copy of the same database that is on the production server.