dsh plugin hub: install a plugin in 3 steps

From the moment you open DSH Plugin Hub from a search result, installing takes three steps: search and read the card, install and read the confirm dialog, restart and verify three signals. Every click has a decision behind it, and following the order beats trial and error.

Learn the five areas first

Hub is not one page; it is five screens. Knowing the areas prevents clicking in the wrong place (source).

1. Market: the default page, with search, result count, sorting, and categories for narrowing the list.
2. Installed: plugins currently installed in the profile, where updates, uninstalls, and configuration live.
3. Custom Install: packages not in the catalog, installed by npm name, GitHub reference, or a dsh command.
4. Settings: update checks, npm mirror, proxy, security trust, and reset to defaults.
5. System Logs: install, load, and runtime records by category and level; the first place to look when something fails.

For a first installation, only the first two screens matter. Market finds, Installed verifies. Leave custom install and settings alone until the basic chain works.

The result count is a useful signal. It tells you how many entries match. Zero does not always mean nothing exists; it can mean the index has not loaded or the keyword is wrong.

Step one: search and read the card

The goal is not to find a name; it is to find an entry with a clear source. Same-name plugins are common, and card details matter more than the name.

1. Narrow by category first: memory, browser, interface, model, tools. Categories are more stable than keywords when you know the job but not the name.
2. Then enter a keyword. Chinese names suit concepts, English names suit common terms, and package names suit exact lookups.
3. Check the result count and sorting to confirm you are not looking at a single same-name entry.
4. Read four card fields: source (npm or GitHub), version, update time, and verification status.
5. Open the detail page, confirm owner and package name, then decide whether to install.

Verification status means someone checked the entry, not that it fits you. Compatible version, dependency count, and permission scope still need your review; verified is not a security guarantee.

For same-name entries, read owner first. A generic name may have dozens of sources with identical display names and completely different implementations. Owner and repository URL are the unique identifiers.

If search fails, change the spelling before blaming the index. Chinese to English, English to package name; if all three fail, confirm the repository exists on GitHub or npm.

Step two: install and read the confirm dialog

Clicking Install is the beginning; the confirm dialog is the decision point. It lays out what will be written into the profile.

1. Click Install on the card and wait for the dialog.
2. Check the package name and source: the package must match what you intend, and the source must be a trusted owner.
3. Check version and dependencies: is the version compatible, and is the dependency count reasonable?
4. Confirm and wait for the progress to finish; do not navigate away in the middle.
5. Restart when prompted; do not just refresh the UI.

The package name in the dialog is the only reliable identifier. Display names repeat; package names do not. If the package name does not match, cancel and return to the card.

Pause when the dependency count looks abnormal. A small feature that brings many dependencies may be a wrapper or an unnecessary runtime. Read the detail page before deciding.

Do not click Install repeatedly when progress stalls. Check the install stage in system logs to see whether download, extraction, or dependencies failed; repeated clicks only create more failed records.

Step three: restart and verify three signals

Installation success does not mean the plugin is active. Plugins register during startup; without a restart, the UI will not show them.

1. List signal: the plugin appears in Installed and is not marked failed.
2. Config signal: dsh plugin --profile web list contains the package when you need CLI confirmation.
3. UI signal: after a full exit and restart, the entry, command, or panel appears.

The three signals build from bottom to top. List present but UI missing means restart first; still missing after restart means read the load stage in logs; no load record at all means it was installed into another profile.

Do not treat the install-complete toast as verification. It only means the package was processed. Real verification happens after a restart.

What to do on the Installed screen

Installed is not decoration; daily maintenance happens there.

1. Update: when an update badge appears, click Update and read the confirm dialog; restart after updating.
2. Uninstall: check dependencies before removing a package that others may use, and clean leftover configuration afterward.
3. Configuration: some plugins link to settings from the detail or installed page; changes usually require a restart.

Install and update dialogs are not the same. An update replaces a version and may change compatibility; read the target version and release notes instead of clicking through by habit. Leftovers after uninstall are normal: the directory may be gone while configuration and cache remain, so check residue before reinstalling.

Three stuck cases

Hub installations get stuck for three reasons, each with a diagnostic action.

1. Index empty or loading forever. Check whether categories appear. Categories present but results empty means wait or restart for indexing; no categories means check network and proxy, then compare networks.
2. Compatibility failure. If the dialog or log reports a version mismatch, read the compatible version on the card, upgrade the core, or choose another plugin version. Do not force it.
3. Download or build failure. Read the install stage in system logs: download failures point to network or mirror, extraction failures to disk, build failures to dependencies or blocked scripts.

System logs are the common entry point for all three. Reading the stage before acting beats reinstalling; the stage name tells you which layer failed.

Web page versus built-in entry

The web detail page and the built-in Hub are two entries to the same data. The web is for browsing and sharing; the built-in Hub performs installation.

The web page cannot install for you. It provides information and a command; writing to the profile must happen locally. Understanding this prevents hunting for an Install button on a web page.

Next steps

Install one, verify three signals, then install the next. If you have never opened the market, read First five minutes in the DSH plugin market. If installation fails, read How to read Hub notifications. To understand the division of Hub, CLI, and GitHub, read Three ways to find a DSH plugin.

Sources: DSH Plugin Hub 2.2.5 screenshot index, dshplugin/dsh-plugin-hub, dsh CLI README, DSH Plugin Hub plugin page