All-Round WeiLin Prompt Editor

This is the flagship node in WeiLin-Comfyui-Tools, and the name is honest about it - "all-round" means it wants to be your prompt box, your tag manager, and your LoRA stack all at once, in a single node. If WeiLinPromptUIWithoutLora is the lean version, this is the one where the author decided you shouldn't need a separate LoRA loader node at all.

Why you'd reach for it. The rest of the ComfyUI ecosystem solves prompting and LoRA-stacking as two separate problems - you type tags into a CLIP Text Encode, then wire in rgthree's Power Lora Loader or a chain of plain LoraLoaders to handle the models. WeiLin merges them: LoRAs get referenced as tags inside the same text you're already editing, using the pack's own syntax, <wlr:LoraName:modelWeight:textWeight>. Add one through the node's built-in LoRA manager (browse your installed LoRAs, pull trigger words and preview images pulled from CivitAI, click add) and it drops straight into your prompt as one of those tags, weight and all. It's the same instinct as rgthree's Power Lora Loader - never leave the graph to manage a LoRA - just expressed as text-in-the-prompt instead of one widget row per LoRA. Whether that's more convenient than a dedicated stack node is a matter of taste; some people find embedding LoRA syntax inside prompt text harder to scan at a glance than rgthree's toggle rows, and it's worth trying both before you commit to a workflow around either.

How it works. Same editor as its sibling node - tag manager, Danbooru autocomplete, translation - but now the LoRA manager panel lives in the same window. The tags you build (including any <wlr:...> LoRA references) get written into positive; the LoRA references specifically also populate lora_str, which the node parses separately to patch the incoming model and CLIP before conditioning happens. temp_lora_str looks like the pack's scratch field for LoRA edits in progress - you shouldn't need to touch it directly, it's there for the editor UI's own bookkeeping.

Inputs that matter. positive (required) is your prompt text. auto_random (required) turns on the pack's random-tag generator, paired with the optional random_template - define a template once and every run picks a fresh combination, handy for batch variation runs. lora_str (optional) holds the parsed LoRA-tag references if you're using that feature. opt_clip and opt_model are the CLIP and MODEL you want the node to actually patch with those LoRAs - wire both in if you want this node to do the whole job; skip them and you're just using it as a fancy prompt box, same as its "without Lora" sibling. opt_text again takes a wildcard input for merging text from elsewhere in the graph.

Outputs. STRING is the assembled prompt. CONDITIONING populates once opt_clip is wired. CLIP and MODEL come back out LoRA-patched if you fed both in - which is the point of this node over the plain one, since it means you can go checkpoint → this node → sampler with no separate LoRA loader anywhere in the graph. Like its sibling, it's flagged as an output node so ComfyUI always runs it regardless of what's downstream.

Install. Via ComfyUI Manager, search "WeiLin-Comfyui-Tools". Manually: cd ComfyUI/custom_nodes && git clone https://github.com/weilin9999/WeiLin-Comfyui-Tools, restart. No extra model downloads for this node - it reads whatever LoRAs and checkpoints are already in your standard folders.

Common issues. Because this node does more - parsing prompt text, LoRA tags, and patching a model in one pass - it's the one most likely to feel sluggish or behave oddly if you leave auto_random switched on across several unused copies of it sitting in a graph; turn it off on anything you're not actively wiring up. If LoRAs referenced via <wlr:...> tags don't seem to apply, first check the plain fundamentals that trip up every LoRA loader on any pack: base-model mismatch between the LoRA and your checkpoint, and a missing trigger word in the prompt (the node's LoRA manager can pull trigger words for you, which is worth using rather than guessing). As with the rest of the pack, updates need a real restart, not a Manager reload, since the LoRA and tag features run through the pack's own server routes. And the same honest caveat as its sibling applies: some users coming from webui prompt tools find this UI takes more steps than they expected, so give it a real test run before restructuring a workflow around it.