wgp.py --process silently ignores all enabled plugins

[CodeBarrie]

Summary

wgp.py --process <file> runs the queue without loading any plugin. Every entry in enabled_plugins is silently ignored, with no warning in the output, so a batch run behaves as though the user has no plugins installed.

Cause

initialize_plugins() is only ever called from inside create_ui():

wgp.py:13515   def create_ui():
wgp.py:13555       app.initialize_plugins(globals())

and the --process branch always exits before the UI is built:

wgp.py:13826   if len(args.process) > 0:
                   ...
wgp.py:13890       sys.exit(0)
wgp.py:13912       sys.exit(0 if valid_count == len(queue) else 1)
wgp.py:13918       sys.exit(0 if success else 1)
wgp.py:13921       sys.exit(130)

wgp.py:13986   demo = create_ui()          # never reached in --process mode

So app.plugin_manager is constructed (wgp.py:2689) but load_plugins_from_directory() never runs.

Reproduction

With any plugin enabled in wgp_config.json that logs on load:

python wgp.py --process settings.json --output-dir out/

The generation completes normally and the plugin produces no output of any kind. The same settings through the web UI load it.

Why it matters

The failure is silent and looks like a null result rather than a missing component. I lost two full A/B runs to it: I was measuring a model-patching plugin with the plugin on in one leg and off in the other, and both legs were in fact stock WanGP. Nothing in the log said so — the only clue was the absence of lines I expected to see.

Anyone using --process for batch work is getting unplugged behaviour without being told. Plugins that patch model internals are the worst case, since the output still looks plausible.

Suggested fix

Call app.initialize_plugins(globals()) in the --process path before the queue runs, or hoist it out of create_ui() into the startup path both branches share.

If loading plugins headlessly is deliberate — some plugins build Gradio components at load and may not be safe without a UI — then printing one line saying plugins are disabled in CLI mode would remove the ambiguity entirely.

Workaround

For anyone hitting this: plugin loading is separable from the plugin manager when the plugin only patches Python objects. A sitecustomize.py on PYTHONPATH that waits for the target module to finish importing and then calls the plugin's own install function works headlessly.

Environment

• WanGP 362c346
• Windows 11, Python 3.11, torch 2.10+cu130, RTX 5090

[Tophness]

Is there any reason you would need plugins enabled in headless mode?

If not, ideally they should be disabled imo. The plugin system is not exactly optimal, it's fairly easy to slow down lower end systems under certain conditions.
The version that was released was just efficient enough that you could try to optimize your plugin and make decisions for yourself as a user if you had too many plugin slowing down your UI, because the more efficient methods were relatively unstable.