Download the PHP package webrium/console without Composer
On this page you can find all versions of the php package webrium/console. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package console
Webrium Console
A command-line toolkit for the Webrium PHP framework. Provides commands for scaffolding files, managing databases, inspecting logs, and installing plugins.
Requirements
- PHP 8.1+
- Symfony Console 6.4+
Installation
Available Commands
| Command | Description |
|---|---|
init |
Create the project directory structure |
make:model |
Generate a model file |
make:controller |
Generate a controller file |
make:route |
Generate a route file |
make:migration |
Generate a database migration file |
make:seeder |
Generate a database seeder file |
migrate |
Run, roll back, or inspect database migrations |
db:seed |
Run database seeders |
call |
Call a method on a controller or model |
db |
Manage databases |
table |
Manage database tables and execute SQL files |
log |
Manage log files |
plugin:install |
Install a plugin |
plugin:update |
Update an installed plugin |
plugin:remove |
Remove an installed plugin |
plugin:list |
List installed plugins |
plugin:info |
Preview a plugin without installing |
plugin:new |
Create a plugin authoring definition |
plugin:export |
Export a distributable plugin package |
plugin:config:compile |
Compile the plugin registry with project overrides |
init
Creates all standard Webrium project directories.
make:model
Generates a model file in the models directory. Without --table, creates a simple model. With --table, creates a database-connected model.
| Argument / Option | Description |
|---|---|
Name |
Model class name (e.g. User) |
--table, -t |
Database table name. If omitted, the name is auto-converted to snake_case and pluralized |
--no-plural |
Prevent automatic pluralization of the table name |
--force, -f |
Overwrite if the file already exists |
make:controller
Generates a controller file in the controllers directory. Automatically appends Controller to the name if not already present.
| Argument / Option | Description |
|---|---|
Name |
Controller name (e.g. User → UserController) |
--namespace |
Custom namespace (default: App\Controllers) |
--force, -f |
Overwrite if the file already exists |
make:route
Generates a route file in the routes directory.
| Argument / Option | Description |
|---|---|
Name |
Route file name (e.g. Api → Api.php) |
--force, -f |
Overwrite if the file already exists |
make:migration
Generates a timestamped migration file in database/migrations. Builds on top of webrium/foxdb's migration system (Foxdb\Migrations\Migration, Schema, Blueprint).
| Argument / Option | Description |
|---|---|
name |
Migration name, e.g. create_posts_table or add_status_to_posts_table |
--table, -t |
Explicit table name. If omitted, it's inferred from the migration name |
--force, -f |
Allow generating another migration with the same descriptive name |
The generated stub depends on the naming convention used:
create_..._table→ uses the create stub, withSchema::create()already wired up and a ready-to-runid()+timestamps()example.add_..._to_..._table/remove_..._from_..._table→ uses the update stub, with an emptySchema::table()block in bothup()anddown()for you to fill in.- Anything else falls back to the create stub.
In every case the table name is inferred automatically from the migration name, unless --table is given explicitly.
migrate
Runs database migrations from database/migrations using webrium/foxdb's Migrator. Tracks applied migrations in a migrations table, batched the same way per run so a whole batch can be rolled back together.
| Action | Description |
|---|---|
run (default) |
Apply all pending migrations |
rollback |
Roll back the last batch (or --step migrations) |
reset |
Roll back every migration that has been run |
refresh |
Roll back everything, then run all migrations again |
status |
Show which migrations have run, and in which batch |
| Option | Description |
|---|---|
--step |
Limit run/rollback to a specific number of migrations |
--connection, -c |
Run against a named connection instead of the default one |
--seed |
After a successful run or refresh, also run every seeder in database/seeders |
--force, -f |
Skip the confirmation prompt for reset/refresh |
Each migration runs inside its own database transaction. If a migration fails, migrate stops and reports it — earlier migrations in the same run stay applied, matching the underlying Migrator::run() behavior.
make:seeder
Generates a seeder class in database/seeders. Seeders populate the database with default or test data (admin users, lookup tables, categories, etc.) and are built on top of webrium/foxdb's Foxdb\Seeders\Seeder base class.
| Argument / Option | Description |
|---|---|
Name |
Seeder class name (e.g. UsersSeeder). Auto-converted to PascalCase if given in snake_case |
--force, -f |
Overwrite if the file already exists |
The generated stub looks like:
Inside a seeder you can chain to other seeders with $this->call(...), which accepts a class name or an array of class names. This is the recommended way to build a master seeder that orchestrates the others.
db:seed
Runs database seeders from database/seeders using webrium/foxdb's SeederRunner. Unlike migrations, seeders are not tracked — every invocation runs them fresh, so they should be written to be idempotent if you intend to run them more than once.
| Argument / Option | Description |
|---|---|
class |
Optional. Class or file name of a single seeder to run. If omitted, every seeder in database/seeders is executed in alphabetical order |
--connection, -c |
Run against a named connection instead of the default one |
--no-transaction |
Do not wrap each seeder in a transaction (use when seeders contain DDL or are intentionally non-atomic) |
--force, -f |
Skip the production confirmation prompt (relevant only when APP_ENV=production) |
Each seeder runs inside its own transaction by default, so a failure mid-seed rolls back any inserts from that seeder. If a seeder fails, db:seed stops and reports it — seeders that already completed remain applied.
When APP_ENV is set to production (or prod), db:seed asks for confirmation before running. Pass --force to bypass the prompt in automated environments.
call
Calls a method on a controller or model class directly from the terminal.
| Argument / Option | Description |
|---|---|
Class@Method |
Class and method name (e.g. UserController@index) |
--params, -p |
JSON array of arguments passed to the method (default: []) |
--model, -m |
Target a model instead of a controller |
--namespace |
Custom namespace (default: App\Controllers or App\Models) |
db
Manages databases.
| Action | Description |
|---|---|
list |
List all databases |
tables |
List tables in a database |
create |
Create a new database |
drop |
Delete a database (prompts for confirmation) |
| Option | Description |
|---|---|
--use, -u |
Specify a database for the tables action |
--force, -f |
Skip confirmation prompt when dropping |
table
Inspects and manages individual tables, and can also execute SQL files against a database.
| Action | Description |
|---|---|
info |
Show table information |
columns |
Show column details (name, type, nullable, key, default, extra) |
drop |
Delete the table (prompts for confirmation) |
truncate |
Remove all rows from the table (prompts for confirmation) |
rename |
Rename an existing table |
copy |
Copy table structure to a new table |
exists |
Check whether a table exists |
count |
Count rows in a table |
run |
Execute a SQL file (<table_name> is treated as a file path) |
| Option | Description |
|---|---|
--use, -u |
Specify a database |
--force, -f |
Skip confirmation prompts for destructive actions |
log
Manages Webrium log files stored in the logs directory.
| Action | Description |
|---|---|
list |
List all log files |
latest |
Display the most recent log file |
file <name> |
Display a specific log file by name |
clear |
Delete all log files |
Plugin System
Webrium Console includes a full plugin system for installing and managing distributable components.
The source argument accepts a local .zip file path or an https:// URL:
When plugin:update succeeds, package-owned fields (name, version,
description, author, hash, files, and meta) are refreshed from the new
package. Project/runtime fields (status, active, and installed_at) and
unknown extension fields are preserved. The plugin also remains in its existing
registry position. Backups preserve project-relative paths so files with the
same basename do not overwrite one another.
Plugin paths and a separate authoring repository
By default, plugin:new reads and writes definitions under
storage/app/plugins/definitions, and plugin:export writes packages under
storage/app/plugins/dist. The installed registry, optional project overrides,
compiled output, and backups also use their conventional project paths.
Every path can be configured independently in .webrium.conf.json. Paths must
be relative to the project root and may not escape it:
This keeps project-owned registry and override files in the project repository, while definitions and distributable packages can live in a dedicated authoring repository:
console.plugins is the only configuration source for plugin-system paths.
Projects without this configuration retain the original default paths.
Project overrides and compiled configuration
plugins.json is the registry managed by plugin lifecycle commands.
plugins.overrides.json is an optional, project-owned customization layer. Its
plugins object is keyed by installed plugin name:
Compile and validate the effective registry after changing either source:
JSON objects merge recursively. Numeric arrays are replaced in full, never
merged by index. Package-owned fields such as version, files, and hash
cannot be overridden. An unknown plugin name or invalid override fails without
replacing the last valid compiled file. Registry changes made by install,
update, or remove invalidate the compiled file so stale output is not consumed.
The compiled file is derived cache data and should not be committed.
For full documentation on creating and distributing plugins, see the Plugin System Wiki.
License
MIT
