String Edit

The name is a bit of a lie. String Edit ships inside MW-ComfyUI_OneButtonPrompt, a pack billed as "one-click prompt generation," but this node doesn't generate anything and has nothing to do with one click. It's a plain text-plumbing utility: split a string in two, glue two strings together, or just pass one through unchanged. That's the whole job, and if you're building workflows around this pack's prompt-loading nodes, it's the piece that lets you mess with the text between loading a prompt and feeding it to a CLIP text encode.

What it actually does

Under the hood it's embarrassingly simple - a single Python function with five outputs, no API calls, no keys, no models. The text input is marked forceInput, which in ComfyUI-speak means you can't type into it: you have to wire a string in from another node. Don't sit there poking at an empty text box wondering if it's broken.

The outputs:

• text - your input passed through untouched. Useful as a clean re-route when you want one string feeding two places.
• merged_text - text + paste_edit_text concatenated.
• split_1 / split_2 - the two halves if you give it a split_tag.
• edited_text - just paste_edit_text passed through, handy if you want it downstream without re-wiring the source.

The three inputs that matter are text, paste_edit_text, and split_tag; form_right is a boolean that picks whether the split starts from the left (default) or the right.

Where people get burned

Two real traps hide in the source (OneButtonPrompt.py), and both are easy to hit:

1. The split has a "not at the start" rule. The code only splits when text.find(split_tag) > 0 - that's index greater than zero. If your string begins with the split tag, nothing gets split and both split_1 and split_2 come out as empty strings. And since they're empty whenever no split happens, you can't always tell "split produced nothing" from "split never ran."
2. merged_text adds no separator. It's a raw text + paste_edit_text. If your pasted text doesn't start with a comma or space, your prompt arrives as one run-together blob, and a T5/CLIP encoder will happily tokenize photorealisticdetailedportrait as gibberish.

Honestly? If you already run WAS Node Suite or Efficiency Nodes you probably have equivalent string utilities. String Edit earns its keep inside this pack's own graphs - the Load Prompt node's outputs flow naturally into it before sampling - and as a zero-dependency teaching example of how text passes through a graph.

Installing it

ComfyUI Manager → search "MW-ComfyUI_OneButtonPrompt" (or just "OneButtonPrompt") → install, or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/billwuhao/ComfyUI_OneButtonPrompt

Then restart ComfyUI. That's it - the requirements.txt is empty and the code only imports things ComfyUI already ships (torch, PIL, numpy, requests). No model downloads, no heavy deps. One heads-up: the pack was completely rewritten in March 2025 (v1.0.0) and now only ships "starting prompts" meant for an LLM to polish - if an old tutorial references the pack's older auto-prompting behavior, that's gone.

Verdict

This is a genuinely thin node with zero organic search traffic, and it won't change your life if you're outside this pack's ecosystem. But if you're already using OneButtonPrompt's Load Prompt and want to split, merge, or re-route your prompt text before it hits the encoder, it's right there, free of dependencies, and the behavior is fully visible in the source. There are fancier string nodes; there aren't many simpler ones.