WP Manifestindependent plugin directory
manifest / developer / rh-blueprint

RH Blueprint archived self-updates

Wiederverwendbares WordPress-Basis-Plugin: Settings-Hub, Dashboard-Cleanup, DB-Tools, Peer-to-Peer Sync und GitHub Auto-Update.

by Robin Herbeck · github.com/herbeckrobin/rh-blueprint · 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/herbeckrobin/rh-blueprint/archive/refs/heads/main.zip

Ships its own WordPress updater (Plugin Update Checker), so new versions show up under Dashboard → Updates.

Readme github.com/herbeckrobin/rh-blueprint ↗

Wiederverwendbares WordPress-Basis-Plugin von Robin Herbeck. Wird als Grundgerüst in jedes neue Kundenprojekt eingebaut und updatet sich automatisch über GitHub Releases.

Features

  • Settings-Page mit Tab-Kategorien, Live-Suche und pro-Tab isolierten Option-Groups
  • Dashboard-Cleanup ersetzt die WordPress-Default-Widgets durch ein eigenes Widget (Support-Box, Quick-Links, erweiterbare Sections)
  • DB-Tools für Export, Import und Restore. Pure PHP, kein mysqldump, läuft auf Shared Hosting
  • Sync Network für Peer-to-Peer Sync zwischen WordPress-Instanzen über REST-API und HMAC-SHA256
  • Auto-Update über GitHub Releases, eingehängt in die native WP-Update-Mechanik

Voraussetzungen

  • WordPress 6.5+
  • PHP 8.1+

Installation

  1. Neueste ZIP aus Releases laden
  2. In WordPress unter Plugins → Installieren → Plugin hochladen
  3. Aktivieren
  4. Unter Einstellungen → RH Blueprint konfigurieren

Updates

Das Plugin prüft GitHub regelmäßig auf neue Releases (via plugin-update-checker). Updates erscheinen unter Dashboard → Aktualisierungen wie normale Plugin-Updates.

Release-Workflow

  1. Version in rh-blueprint.php bumpen (* Version: 0.5.0)
  2. Commit und Push auf main
  3. Tag erstellen und pushen:
    git tag v0.5.0
git push origin v0.5.0
  4. Die Action release.yml baut ZIP und Release automatisch (Tag-Version muss exakt mit dem Plugin-Header übereinstimmen, sonst bricht sie ab)
  5. Aktive Sites sehen das Update innerhalb von 12h (WP-Cron-Default)

Entwicklung

composer install                 # Dependencies
vendor/bin/phpstan analyse        # Statische Analyse (Level 5)

cd ../../ && ddev start && ddev launch    # Lokales Test-WordPress

Das Plugin ist per Symlink in Code/wp/wp-content/plugins/rh-blueprint eingebunden.

Architektur

rh-blueprint/
├── rh-blueprint.php      # Plugin-Header, Autoloader, Bootstrap
├── composer.json         # PSR-4 RhBlueprint\ -> inc/
├── vendor/               # Committed (Shared-Hosting-Kompatibilität)
├── inc/
│   ├── Plugin.php        # Singleton-Bootstrap
│   ├── helpers.php       # Globale Helper
│   ├── UpdateChecker.php # GitHub Auto-Update
│   ├── Settings/         # Tab-basierte Settings-Page
│   ├── Admin/            # Dashboard-Cleanup, Widget, DB-Tools
│   ├── Db/               # BackupStorage, Exporter, Importer, SearchReplace
│   └── Sync/             # Peer-Registry, HMAC-Auth, Sync-Network
├── assets/               # Admin-Assets
└── .github/workflows/    # Release-Automation

Sync Network

Beim Pull/Push dumpt der Exporter die Datenbank und importiert sie auf der Ziel-Seite. LocalOptionGuard und SyncDefaults::excludedTables() schützen site-spezifische Daten vor dem Überschreiben.

Geschützt (bleiben auf dem Ziel unverändert): plugin-eigene Options (rhbp_*), Site-Identität (siteurl, home, admin_email), Plugin-Aktivierung (active_plugins), cron, rewrite_rules, Hosting-Pfade, WP-Core-SMTP, DB-Schema-Versionen, Update-Transients sowie Options von Limit Login, WP Mail SMTP und WPS Hide Login.

Vom Export ausgeschlossen: wp_actionscheduler_* und wp_woocommerce_sessions.

Erweiterbar via Filter:

add_filter('rh-blueprint/sync/preserved_option_names', fn(array $n) => [...$n, 'custom_api_key']);
add_filter('rh-blueprint/sync/preserved_option_patterns', fn(array $p) => [...$p, 'my\\_plugin\\_%']);
add_filter('rh-blueprint/sync/excluded_tables', function (array $t) {
    global $wpdb;
    $t[] = $wpdb->prefix . 'visitor_tracking';
    return $t;
});

Bekannte Grenzen

  • wp_users + wp_usermeta werden komplett gesynct. Admin-Passwörter wandern mit, der User-Satz auf dem Ziel wird ersetzt. Für lokal → Stage im selben Projekt unkritisch, für echte Kunden-Syncs ein Problem. Ein UserGuard ist geplant.
  • Kein Background-Job-Modus. Export und Import laufen synchron im REST-Request. DBs über ~50 MB können ins HTTP-Timeout laufen. Action-Scheduler-Integration ist geplant.
  • Kein Rate-Limiting. Ein Peer mit gültigem Token kann beliebig viele Syncs triggern.
  • Keine Medien. Nur Datenbank-Tabellen werden transferiert, Upload-Files nicht. Dafür braucht es zusätzlich rsync o.ä.

Lizenz

GPL-2.0-or-later