Text Replace (Legacy)

Here's the honest thing about Text Replace (Legacy): it is not a different node. In the pack's source code, DebugPadawan_TextReplace and DebugPadawan_TextRegex are literally the same Python class - the "Legacy" name is kept around so workflows saved against the old node name still load, and you get the same regex engine either way. The README still describes it as a simple literal find/replace, but what actually ships is pattern-based, capture-group-aware regex substitution.

So the real question isn't "which one should I use," it's "what is this node, really." And the answer: the same search-and-rewrite tool as Text Regex (Pro). You feed it text, a pattern, and a replace string, and it rewrites every match using Python's re module - backreferences like \1 and \2 included. The default example reformats a phone number: pattern (\d{3})-(\d{3}-\d{4}), replace (\1) \2, giving (123) 456-7890.

The inputs and outputs

• text - the string to process.
• pattern - the regex to find. This is the trap: it's treated as regex, not literal text. A pattern of sunset works fine as plain text, but a pattern of a.b matches "a" + any character + "b", not the literal characters a.b. If you genuinely want literal replacement, escape special characters (\. for a dot) or use Text Prefix/Suffix-style thinking and a different tool.
• replace - the substitution, backreferences allowed.
• flags - IGNORECASE, MULTILINE, DOTALL, or None.

Outputs: text (the rewritten string), matches (a list of what matched), and found (boolean - useful for conditional branching).

Why keep both names

Backward compatibility, plain and simple. The pack's author merged replace into the regex node and left a duplicate registration under the old class name so that anyone who saved a workflow with "Text Replace" doesn't get a missing-node error on load. Both names run identical code. The practical upshot: pick one, use it consistently, and don't worry that the "Pro" variant is more capable - it isn't, and the "Legacy" one isn't crippled. The only reason to prefer Text Regex in new graphs is clarity for whoever reads the workflow later.

Installation

Same pack either way:

cd ComfyUI/custom_nodes
git clone https://github.com/DebugPadawan/DebugPadawans-ComfyUI-Essentials.git

or install "DebugPadawan's ComfyUI Essentials" via ComfyUI Manager, then restart. No models, no heavy deps for this node - pure re.

Gotchas

Because it's regex, invalid patterns return the literal string Regex Error: ... as the text output instead of crashing - useful, but easy to miss downstream. And the matches list stringifies tuples when your pattern has capture groups, so expect ("123", "456-7890")-style entries rather than flat strings. Both quirks are shared with Text Regex (Pro), because, well, it is Text Regex (Pro).