Managing false positives in WAF policy

Situation overview:
1) a Wordpress server that has always been under heavy attack was recently moved behind a F5 WAF
2) the WAF is dropping malicious traffic (thank you F5!)
3) the WAF is also dropping legitimate POSTing of user content with several signatures (Server Side Code Injection, SQL-Injection, Cross Site Scripting (XSS))
4) there is no QA/Test instance; there is no opportunity here for a controlled "learning/staging" process; the server is in production

Example false positive:
One user wants to embed videos on their site. The XSS signature is set off by script tags bracketing a URL pointing to the Vimeo player. The XSS signature fires off during the POSTing of this content to the site.

WAF Suggestion:

Suggested Action: Disable the matched signature on the matched Parameter
Matched Parameter: *
Matched Attack Signature: 200001475 - XSS script tag end (Parameter) (2)

I could choose to click on 'Accept', but I am concerned that the use of a wildcard parameter means script tags will be accepted anywhere, rendering the XSS signature useless. Is that a correct interpetation?

Solution?:
I have whitelisted some known source IP addresses, but that will not satisfy a user base who wants to update content from anywhere at anytime.
There are some Wordpress-specific cookies I can leverage. Looking at the WAF policy Cookie List, however, it appears its focus is to validate as allowed or denied. But that doesn't seem to tie a cookie to a signature. In other words, if you see these valid cookies, then bypass this signature.

It looks like I have two options.

One, write a custom signature to catch legit POSTs (regex search for specific cookies), and disable blocking for this signature.

The other option would be an iRule, like this:

if {HTTP::method is POST and HTTP::URI contains "someURI"} {
if {cookie1="foo" and cookie2="bar"} {
  ASM::disable
}
}

Thank you for taking the time to read this. I welcome any feedback.