Nathan Arthur

@TomJNowell Thank you for the tip!

which handles validation and optional route segments.

It also handles routes like { language }/audiobooks/stories/{ entity_id:[0-9]+ }[/{ slug }]

But I feel like I've made things much more complex then they perhaps need to be.

Basically I have a large part of the plugin dedicated to taking routes like { language }/audiobooks/stories, translating them, and generating the regex needed for add_rewrite_rule.

This is all due to a pretty complex home-grown routing system... You wouldn't know of any good examples of other people abstracting routing in a WordPress plugin?

Thank you so much for your help, @Howdy_McGee!

That was it. I was already filtering the redirect, and I wasn't including the query string in what I returned. I feel like I've overcomplicated my solution. =P

I just confirmed that the redirect is happening via redirect_canonical by putting a var_dump on that filter.

Right...

Oh, hmm. Ok.

Except the second entry doesn't say from ServiceWorker =P

Maybe this is a PWA issue =P

Status Code: 301 Moved Permanently (from ServiceWorker)

I just looked in the Network panel and I am getting an initial 301. Is that normal for a rewrite rule?

Turned everything else off, resaved permalinks, and confirmed I get 404s for everything else. Didn't fix it.

I'll try turning the other rewrites off.

Ok

Do I need to match the query string in the regex for the rewrite rule and then append it to the result query?

Would that prevent a query string from getting through?

There is a custom rewrite applied to this page.

Hmm, I'll try...

matched_rule and matched_query in the dumped query look right.

How might that interfere?

Yes, a lot. =P

And it shows up in the public_query_vars section of the dumped query object.

public function registerQueryVar($vars)
{
    $vars[] = 'avorg_query';
    return $vars;
}

Using add_filter('query_vars', ...) ? Yes

Without the dump, get_query_var returns nothing

However, that seems to cancel the redirect (?) and the page doesn't load, just the dumped data.

If I dump the query on parse_request, the query param shows up in the data.

The var I'm testing with is avorg_query=... so I don't think so...

I tried using the query_vars filter and the add_rewrite_tag function to register the query var, but it still gets stripped.

Any tips on preventing a rewrite rule from removing a query var? I've got a rewrite rule for /the/page, but visiting /the/page?my_var=value ends up at just /the/page without the query string.

I figured out my issue. I had a misbehaving callback that was forcing a 404 to be thrown.

I'm using the Query Monitor plugin to try to debug this: wordpress.org/plugins/query-monitor

Two different URLs, the correct rewrite rule is matched in both cases, and the correct query strings are generated. But with one URL page_id isn't included in the query, so the page isn't found, while with the other URL it is included and the page loads properly.

Does anyone have an idea why a query variable would make it into the page query for some rewrite rule matches, and not others?

Ok, thanks, maybe I'll go ahead and ask :)

That'd probably be fine, I'd just like to make as difficult to break the website as I can.

@TomJNowell Either that, or I want to turn them on from the plugin. Either is viable for me since this is a plugin for a single website.

This is a plugin for internal use, so I'm not concerned about forcing pretty permalinks to be on.

My plugin successfully adds the rewrite rule, but it only gets used if I manually turn on pretty permalinks, which I don't want to require.

Anyone know how I can turn on permalinks programmatically so my add_rewrite_rules will work on plugin install?

@fuxia Thanks! I'll look into that

Quick question: Developing a plugin, and need to know in php whether the plugin is currently in my dev environment or not, so I can toggle Twig caching accordingly. What's the best way to do that?

Haha! That's great.