Text Find and Replace Input
Find/replace terms wired in, not typed
WAS's regular Text Find and Replace does a plain substring swap, but the find term and the replacement are typed straight into the node as fixed text. Text Find and Replace Input is the same idea with one change: those two values come in as graph inputs instead of hardcoded widgets, so they can be produced by something else in your workflow and change every run.
A quick honesty note up front: this exact node isn't named in the pack's own README - the README lists Text Find and Replace and Text Find and Replace by Dictionary, but not this one by name. WAS has a consistent naming pattern elsewhere, though (compare Text Add Tokens vs Text Add Token by Input, where the "Input" sibling swaps a typed widget for a wired-in value) - this node fits that same convention. Treat the mechanics below as the reasonable inference that convention supports, not a direct quote from the docs.
Why you'd reach for this instead of the plain version
The typed version is fine for a fixed placeholder - swap SUBJECT for a fox every time by hand. The input version is for when the find term or the replacement itself is computed: pulled out of a dictionary with Text Dictionary Get, picked randomly with Text Random Line, or built by concatenating other node outputs. Anywhere you want the substitution itself to be dynamic rather than something you retype in the node's UI, this is the version that lets you wire it.
How it works
Same core mechanic as the plain node - scan the input text for the find string, swap every occurrence for the replacement, output the result. The difference is purely where find and replace come from: sockets fed by upstream nodes rather than fields you fill in on the node itself.
The inputs and outputs that matter
Three text inputs: the text to operate on, the substring to find, and the substring to replace it with - all wired in rather than typed, which is the whole point of this node existing alongside the plain version. The output is the rewritten text, ready to feed into a CLIP encode, another text node, or a filename token.
How to install it
Ships with WAS Node Suite.
ComfyUI Manager: search "WAS Node Suite," install, restart.
Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui
then install requirements.txt against your ComfyUI Python and restart. String handling only - no model, no download.
Common issues & troubleshooting
Nothing changed. Same caveats as the plain Find and Replace: matching is exact and typically case-sensitive, so whatever's feeding the "find" input has to match the source text character-for-character. Print the wired-in find value with a Text to Console node before assuming the replace logic is broken - it's usually the upstream value that's wrong, not this node.
It replaced more than expected. This is still a substring match, not a word-boundary or regex match - if the find value happens to be a common fragment of other words in your text, it'll hit those too.
Whole pack fails to import. The standard WAS gotcha: unmaintained since December 2023, and a ComfyUI update can desync its pinned dependencies, throwing "Import Failed" across every WAS node at once. Reinstall requirements.txt against your actual ComfyUI Python and restart - that clears it in most cases.
Inputs (0)
No inputs
Outputs (0)
No outputs