XBHH 预设管理（配方）

If you stack more than three LoRAs, you know the problem. Your loader has become a settings file made of nodes - weights at 0.65, one toggled off, a trigger-word order you tuned over an evening - and wanting that exact combination in a different workflow means saving a whole template or retyping numbers from memory. XBHH 预设管理（配方） exists to make that combination a thing you can click.

Read the Python file and it's funny: emit_preset takes two strings and returns them. All the work happens in a DOM panel bolted into the node on the frontend, which is why it looks like an empty box until you know what you're looking at.

What a "recipe" is here

A recipe is a saved unit of a LoRA list plus weights plus a prompt, maintained in this pack's own LoRA manager page (sidebar button, /xbhh/lora-manager). They live in ComfyUI/user/xbhh/settings.json with a name, category, tags, rating, preview image and prompt. Recipes export as share files, and any LoRAs you're missing get flagged for the pack's Civitai re-download.

This is a different bet from the ecosystem default. For most people the LoRA stack is rgthree's Power Lora Loader - but rgthree's model is per-node state, with no cross-workflow library. This pack's model is a database with a UI on top, aimed at people who collect hundreds of LoRAs and lose track of which ones go together. The interface is thoroughly Chinese-first, which tells you who it was built for.

How the write actually happens

The panel (web/js/recipePresetManager.js) lists your recipes as cards, pulled from the pack's own backend route. Click one:

• For each LoRA in the recipe it builds a preset line - enabled|name|weight|clip_weight||trigger_weight - joined by newlines, then pushes that into the LoRA stack nodes on your canvas through the pack's frontend bridge. No wires. The rows visibly change.
• For the prompt: if the recipe has a non-empty prompt, it lands in the text box of whatever node the prompt output is linked to. Empty prompt, no overwrite.
• Click the same recipe card again and it undoes, restoring rows and preset text from a snapshot stashed in the node's properties. One snapshot per stack; a second recipe replaces it.

The two hidden widgets hold the applied values: preset_text (single-line) carries the stack dump, prompt_text (multiline) the prompt. Python just emits them.

Inputs and outputs that matter

You will not type into either input. preset_text and prompt_text are STRING widgets the JS hides on load - the panel writes to them. If you see two plain text fields instead, the frontend script didn't attach and the rest of the node won't work.

The outputs are the escape hatch for everything the zero-wire path can't do: preset_text wires into a Lora stack Plus node's lora_preset input, and prompt wires into your CLIP text encode (or the pack's Prompt Formatter). Wire preset_text up and that connected stack counts as a target automatically - handy with multiple stacks.

The catch: the backend never reads your recipe library, it echoes whatever string the panel last wrote. A queued run - API, headless, batch script - uses the recipe saved into that workflow file. Clicking a new card rewrites the widgets and the graph state, but nothing re-reads it at execution time.

Install

Manager → search xbhh → install → restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/xbhh123456/Comfyui-xbhh-main.git
cd Comfyui-xbhh-main
pip install -r requirements.txt

The only pip dependency is openpyxl (for the pack's XLSX viewer). No models. Then Ctrl + F5 - this node is ~1000 lines of frontend JS and a cache miss makes it look broken. First startup creates ComfyUI/user/xbhh/ - recipe library and LoRA DB - and that folder survives upgrades.

Where people get burned

An empty panel almost always means an empty library, not a broken node. Recipes are created in the LoRA manager page, not in the node. Scan your LoRAs, tag them, make recipes, then put the node on the canvas - skip step three and you have a node with nothing in it.

"未找到画布桥接，请刷新页面后重试" - the panel couldn't find the pack's graph bridge. Nine times out of ten that's a stale frontend cache, not a lost cause.

Only stacks of type XBHHMultiLoraLoaderPlus are checkable targets. If you're on the pack's basic Multi Lora Loader, that stack won't show in the checkbox list - use the wiring path instead.

And the structural one: this node's whole value lives in addDOMWidget plus node.properties, precisely the surface the Nodes 2.0 frontend rewrite broke for rgthree. Eight months on, that issue is still open, with LoRA toggles only redrawing after a node resize. A single-author pack has less capacity to chase that than a funded one.