WP Manifestindependent plugin directory
manifest / updates / pawa-git-installer

Pawa Git Installer

by Patrick Mwange · github.com/mwangepatrick/pawa-git-installer · website

★ 0stars
0forks

Install

No release zip yet. The repository archive installs, but the folder name will carry the branch suffix and updates will not flow:

wp plugin install https://github.com/mwangepatrick/pawa-git-installer/archive/refs/heads/main.zip

Pawa Git Installer is a WordPress admin plugin for installing and updating other plugins directly from git repositories. It is built for teams that ship plugins from GitHub, GitLab, Bitbucket, or self-hosted git servers and want to manage those deployments from inside WordPress.

Features

  • Install WordPress plugins from public git repositories
  • Install WordPress plugins from private git repositories
  • Support for GitHub, GitLab, Bitbucket, and generic git providers
  • Manual install, update, and update-check actions from wp-admin
  • Scheduled update checks through WP-Cron
  • Built-in GitHub Guides page with official setup links for PAT, SSO, and SSH
  • Optional automatic background updates per repository
  • Branch-based tracking for plugin deployments
  • Detection of the installed plugin file and plugin version after sync
  • Credentials stored in the WordPress database
  • Secret encryption when OpenSSL is available on the server
  • SSH repository support for environments with deploy keys already configured

Requirements

  • WordPress 6.0 or later
  • PHP 7.4 or later
  • A working git binary available to the web server or PHP process
  • File write access to wp-content/plugins
  • Network access from the server to the remote git provider

How It Works

Each managed plugin is registered inside Pawa Git Installer with:

  • a repository name
  • a git provider
  • a repository URL
  • a branch to track
  • a target directory under wp-content/plugins
  • an authentication method
  • optional automatic update behavior

When you install a repository, the plugin runs git clone into the configured target directory. When you update, it runs git fetch, git checkout, and git pull against the configured branch. After sync, it scans the installed plugin folder to detect the main WordPress plugin file and reported plugin version.

Supported Providers

  • GitHub
  • GitLab
  • Bitbucket
  • Generic git hosting
  • Self-hosted git over HTTPS or SSH

The current implementation is provider-aware for default token usernames, but it still uses standard git commands underneath rather than provider-specific APIs.

Authentication Modes

Public Repositories

Use the repository HTTPS URL and set authentication to None.

Example:

https://github.com/example/my-plugin.git

Token Authentication

Use HTTPS and set authentication to Token.

Examples:

  • GitHub fine-grained token or PAT
  • GitLab personal access token
  • Bitbucket app password or token-compatible credential depending on host setup

Pawa Git Installer will inject the token into the clone/pull URL when needed.

Username + Password / App Password

Use HTTPS and set authentication to Username + Password / App Password.

This is useful for providers or internal servers that still expect username/password style basic authentication.

SSH

Use an SSH-style repository URL and set authentication to SSH.

Example:

git@github.com:example/my-plugin.git

In this mode, the plugin expects SSH keys and trust configuration to already exist on the server. The plugin does not generate deploy keys or manage known hosts.

Installation

  1. Copy the plugin into wp-content/plugins/pawa-git-installer.
  2. Activate Pawa Git Installer in WordPress.
  3. Open Pawa Git Installer from the WordPress admin menu.
  4. Confirm the environment shows git as available.
  5. If you need help with GitHub credentials, open the GitHub Guides page inside the plugin admin menu.
  6. Add a repository entry.
  7. Click Install to clone the plugin into the configured local directory.
  8. Activate the installed plugin if needed.

Repository Setup Fields

Name

A label shown in the admin screen.

Provider

Used for provider presets and future provider-specific behavior.

Repository URL

The full clone URL for the plugin repository.

Branch

The branch that should be tracked for updates. If left blank, the plugin defaults it to main.

Local Directory

The folder name that will be created under wp-content/plugins. If left blank, the plugin derives it from the repository URL, for example https://github.com/org/my-plugin.git becomes my-plugin.

Auth Type

One of:

  • None
  • Token
  • Username + Password / App Password
  • SSH

Auth Username

Used for basic auth and optionally for token-based auth when the provider expects a specific username.

Auth Secret

The token, password, or app password. Leave blank when editing an existing repository if you want to keep the current stored secret.

Enable Scheduled Checks

Allows the repository to participate in WP-Cron update checks.

Enable Automatic Background Updates

If enabled, the plugin will automatically pull updates after a scheduled check detects a new commit on the tracked branch.

Scheduler

Pawa Git Installer uses WP-Cron for scheduled checks. The global settings page currently supports:

  • enabling or disabling scheduled checks
  • choosing the cron interval
  • enabling auto-update by default for newly added repositories

Available intervals in the current UI:

  • Hourly
  • Twice Daily
  • Daily

Security Notes

  • Secrets are stored in the WordPress database.
  • If OpenSSL is available, secrets are encrypted before storage.
  • If OpenSSL is unavailable, secrets are only obfuscated and should be treated as lower assurance.
  • Repository URLs displayed in the admin UI are masked to avoid exposing embedded credentials.
  • Administrators should still treat the site database and backups as sensitive.

Current Limitations

  • Single-site only; WordPress multisite is not implemented yet.
  • Branch tracking is implemented; tag and release workflows are not yet implemented.
  • Native integration with the standard WordPress updates screen is not implemented yet.
  • Deleting a repository entry does not remove plugin files from disk.
  • The plugin does not run build steps such as Composer, npm, or asset compilation after clone/pull.
  • The plugin assumes the repository already contains a WordPress-installable plugin structure.
  • SSH key management is outside the scope of the plugin.
  • There is no rollback workflow yet.
  • There is no provider API fallback if server-side git is unavailable.

For production use:

  • use dedicated deploy tokens or app passwords with minimal scope
  • prefer read-only credentials where possible
  • use a dedicated branch or protected release branch for deployed plugin code
  • verify the web server user can execute git
  • verify the server can reach your git host over HTTPS or SSH
  • test with one non-critical plugin before adopting it broadly

Roadmap Ideas

  • tag-based and release-based installs
  • rollback to previous commit or tag
  • integration with the native WordPress updates UI
  • install health checks and better diagnostics
  • provider-specific validation for credentials and URLs
  • optional webhook-triggered syncs
  • audit logs for install and update actions
  • multisite support

Changelog

0.1.0

  • Initial public release
  • Repository registry and credential storage
  • Manual install, update, and check actions
  • Branch-based git sync workflow
  • Scheduled checks and per-repository automatic updates