Omni CMS: add HTML signals (dom-only misses response-first detection)

[danielserranoh]

Omni CMS (Modern Campus, formerly OU Campus) matches only via a dom selector (a[href*='a.cms.omniupdate.com/11/']). Response-first / non-headless consumers don't evaluate dom, so Omni CMS goes undetected even when the marker is present in the HTML.

This adds html patterns for the same signal (statically matchable):

• a\.cms\.omniupdate\.com — the Omni CMS edit / last-published link host.
• omniupdate\.com/XSL/Variables — the OmniUpdate ouc XSL namespace.

---

Test websites:

• https://www.stonybrook.edu/
• https://www.fau.edu/
• https://www.aamu.edu/
• https://www.wilkes.edu/

Assisted by Claude Code.

[tunetheweb]

I’m not sure we need this since HTTP Archive only uses Wappalyzer with DOM detection.

Can you explain more why it’s needed?

[danielserranoh]

You're right — for HTTP Archive's DOM-based detection the existing dom rule already fires, so the html patterns are redundant for that crawl. Two things prompted the PR:

1. The existing dom selector is pinned to a specific OU Campus version: a[href*='a.cms.omniupdate.com/11/']. Installs served under a different path (other versions, or the omniupdate.com/XSL/Variables include) are missed even with DOM detection. If useful, I'd rather broaden the dom rule — e.g. a[href*='cms.omniupdate.com'] — since that's the change that actually improves detection here.
2. The html form was aimed at response-first consumers of this dataset that match raw HTML without a headless browser and so can't evaluate dom rules (my use case is an internal fingerprint engine). I understand if that's out of scope for a set tuned to HTTP Archive's DOM crawl.

Happy to convert this to a broadened dom rule and drop the html additions — or close it if the response-first angle isn't something you want to carry here. Which would you prefer?

[tunetheweb]

Happy to broaden the DOM rule.

So you’re using this Wappalyzer code outside of HTTP Archive and that’s why you want to make the change? The HTML selector is deprecated and is known to be slower so don’t really want to spread usage of it much further. Saying that if it’s one these three extra ones I don’t think that’ll cause any issue. But I wouldn’t want to apply this more widely to all DOM selectors.