View Categories

How Commands Work Internally

2 min read

Cointacted Social Terminal uses a modular, extensible JavaScript command engine.
Every command — built-in, custom, or add-on — is powered by the same internal system.

This article explains exactly how commands are detected, parsed, executed, grouped, and displayed inside the terminal.


1. The Command Registry #

At the heart of the terminal is the registry object:

CointactedSocialTerminalTerminal.registry

Every command is a key inside the registry:

registry["wallet"]
registry["help"]
registry["random"]
registry["mycommand"]

Each key maps to a handler function:

function(input) {
    // your command logic
}

✔ Commands are registered at runtime #

✔ Commands can be overwritten #

✔ Add-ons can add more anytime #

✔ Developers can add commands in any JS file #

The registry is the single source of truth for:

  • command availability
  • command groups
  • aliases
  • help output
  • search results
  • command execution

2. Command Structure #

A command entry typically looks like this:

CointactedSocialTerminalTerminal.registry.echo = function(input) {
    cointacted_social_terminal_append_line(input.args.join(" "), "system");
};

The input object includes:

  • raw → the entire input string
  • cmd → the command name
  • args → array of arguments
  • content after the command
  • parsed tokens

Example:

If the user types:

echo Hello World

Then the input object is:

{
  raw: "echo Hello World",
  cmd: "echo",
  args: ["Hello", "World"]
}

This gives developers clean, easy access to command arguments.


3. Command Execution Flow #

When a user types a command:

  1. User hits Enter
  2. Terminal captures the text
  3. It parses:
    • command name
    • arguments
  4. Looks up the command in the registry
  5. Runs the handler function
  6. Anything returned is printed using the output system

If a command doesn’t exist:

Command not found: sometext

This is handled automatically.


4. Command Groups #

Your plugin automatically groups commands into categories such as:

  • CORE
  • USER
  • SITE
  • WALLET
  • NETWORK
  • CLIENT
  • FUN
  • ADMIN

This grouping is stored inside a metadata structure in the plugin.

Each command has:

  • group name
  • description
  • aliases
  • visibility rules (admin, public, safe)

When you type:

help

the terminal loops through the metadata and prints the groups.

When you type:

help wallet

it prints only the commands from that group.

When you type:

help search gas

it searches:

  • names
  • aliases
  • descriptions

5. Command Aliases #

Many commands include synonyms:

clear → cls
about → info
browser → ua
hostname → site
dns → domain
whoami → me

Aliases are registered in the same registry as separate keys that point to the same function.

Example:

registry["clear"] = registry["cls"] = function() {
    ...
};

This ensures:

  • help displays both
  • search finds both
  • both behave identically

6. Permissions & Safe Mode #

Your plugin implements safety rules that automatically block commands for:

  • guests
  • users without proper capabilities
  • non-admins
  • users without certain permissions

Commands can be:

✔ public (safe) #

Available to guests.

✔ user-only #

Requires login.

✔ admin-only #

Shown only to admins.

✔ wallet-dependent #

Runs only if a wallet is unlocked.

Your terminal handles all of this automatically — no extra logic required in custom commands unless you want it.


7. Built-In Processing for Help/Search #

The help system doesn’t need any configuration from developers.

Once you register:

registry.mycommand = function(input) { ... }

It automatically appears in:

  • help
  • search
  • command listing
  • history (when executed)

Your plugin automatically reads the metadata and injects your command.

This makes the system self-documenting.


8. Commands Never Touch Server-Side Code #

Important for WordPress.org safety:

  • Commands run only in JS
  • No eval
  • No PHP execution
  • No file access
  • No shell
  • No WP database access from JS

If developers want PHP integration, they must:

  • use AJAX endpoints
  • REST API
  • custom routes

The terminal does not include any unsafe direct bridge to server code.


Summary #

The internal command system includes:

✔ A global registry #

✔ Parsed arguments #

✔ Automatic help & search #

✔ Group metadata #

✔ Aliases #

✔ Capability filters #

✔ Safe execution #

✔ Custom event dispatching #

This is what makes the Social Terminal a true extensible framework — not just a UI toy.

Leave a Reply

Your email address will not be published. Required fields are marked *