Ian Dunn

This confused/surprised me too, and took me awhile to understand what was going on / how to avoid it. What does the readme mean by the following ? > Multiple...

...and/or maybe an optional config like: ```js htm.bind( React.createElement, { autoFragment: true, } ```

Thanks, that sounds like a good idea to me. I'm having trouble getting it to work, though. Or, it _does_ work in the sense that it successfully wraps the return...

I use [a wrapper that does this](https://meta.trac.wordpress.org/browser/sites/trunk/wordcamp.org/public_html/wp-content/mu-plugins/helper-functions.php?rev=4379#L221), in case that's helpful to anyone else in the mean time. It's for WordPress, rather than Requests directly, but could be easily modified.

Not sure if this'll help, but Automattic/wp-super-cache#121 adds a bunch of filters.

In the meantime, I found a workaround for this. Adding this line to `wp-config.php` will prevent the button from being disabled, and clicking it will successfully flush the cache: `define(...

It'd be good to also include `JSON_REQUEST` in this and 02d6a8e800be11291a7e5b4954fcd5ef4d93d778, for those running v1 of the REST API. Related Automattic/wp-super-cache#22

Actually, I don't think v1 support is all that important anymore. I think most custom v1 endpoints have migrated to v2, or will soon.

Some parts of the config can be tweaked w/ [a custom config file](https://roytanck.com/2022/01/13/tweaking-surge-by-adding-a-configuration-file/).

I guess a third idea would be to try and mirror the functionality of `WP::parse_request()` in JavaScript, but that seems fragile and not future-proof.