what happens when you manually request manually request this?
example.com/forum/?topic=foo

btw all those requests for urls containing query strings should probably be externally redirected to the canonical urls.

also, did you check the web server error log file?

what happens when you manually request manually request this?
example.com/forum/?topic=foo

The PHP page works exactly as expected, so I'm sure that the issue is with the configuration.

also, did you check the web server error log file?

I looked at /var/log/apache2/error_log, but nothing was helpful; just a ton of expected mod_pagespeed warnings. I modified PHP to write errors to MySQL to eliminate duplicates, and it had a few PHP warnings but that's all... again, nothing helpful :-(

I think I figured out the problem. Since I wasn't 301 rewriting, the 4th rule was catching it and rewriting it again:

RewriteRule ^/forum/([a-z-]+)/?$ /forum/index.php?p=$1 [NC,QSA,L]

The "fix" was to add [PT] to the first rule, then change the [L] to [PT] on the other rules. Luckily I vaguely remembered something about that from before, and was able to scroll through my old threads to find the suggestion.

I really don't understand the logic behind [PT], but I mess with the configuration so rarely that I guess I don't really HAVE to understand...

I really don't understand the logic behind [PT]

It's one of those flags that you never have to think about until you move from htaccess to your own server, because it’s implied in directory contexts. It mainly comes into play when the result of a RewriteRule has to interact with a later mod_alias rule.

That's assuming the rule is lying loose in config (in this context, inside a <VirtualHost> envelope counts as “lying loose”). If it’s actually in a <Directory> section, the flag ought to make no difference, so that’s a head-scratcher.

Docs also confirm that [PT] implies [L]. So retaining [L] instead of replacing it is redundant but has no other effect. Er, should have no other effect.

In this case I've moved all of my configuration files to /etc/apache2/conf.d/userdata/ssl/2_4/. It's a bit of a pain to set up because I have to rebuild and restart after every minor change, but in theory it will process faster so... short term pain for long term gain, I guess.

I originally added [L] to that first line and it fixed the immediate problem, but then when the user had an URL like:

example.com/forum/foo/whatever/12345/

it was being rewritten to:

example.com/forum/whatever/12345/?topic=foo

instead of the expected:

example.com/forum/view/index.php?topic=foo&id=12345

That's when I remembered our conversation before, and I went through our old conversations and found the [PT] suggestion. That appears to have fixed all of it.

That's what I don't quite get... if [PT] tells it to "pass through" then it seems to be the same as no flag at all! It would move on to the second rule either way. But if it's redundant with [L], then it shouldn't have allowed the second rule to run.

Unless it's more like, "stop here, but rerun all rules from the top and remember this new path without redirecting"?

[PT] means “treat the target of a Rewrite as an URL rather than as a filepath”. That's why it has to be implied in htaccess; the site owner may not even know the physical filepath. (I worked mine out by looking at error logs, which give filepath rather than URL.)

in <Directory> or htaccess
RewriteRule blahblah /some/stuff/here [L]
really takes you to--for example--
/users/yourname/example.com/some/stuff/here [L]

while in the config file the same rule would take you to, literally,
/some/stuff/here
which probably doesn't even exist.

So you have to either use the [PT] flag or change all your targets to give the physical filepath.

:: detour to check something in docs ::

Well, phooey. You can't set a RewriteBase except in a directory/htaccess context, and it refers to an URLpath, not a physical filepath. Don't think I ever appreciated that detail.

Hmm. OK, that's interesting and very helpful! Thanks, Lucy :-D