Alle Änderungen an HIT WP Suite, je Version. Die Versionen entsprechen den Git-Tags (v0.0.0.1 …), das Datum ist das des Tags. Neueste zuerst. Was noch keinen Tag hat, sammelt sich unter Unveröffentlicht und wird beim Taggen zum Versionsabschnitt.
„Fassung" meint die Schnittstelle für Satelliten (HIT_WP_SUITE_API) – sie steigt nur, wenn sich an Bestehendem etwas ändert, nicht mit jeder Version. „Schema" ist der Stand der Datenbanktabellen der Suite (Installer::DB_VERSION).
| Version | Datum | Fassung | Schema | PHP / WordPress | Kern |
|---|---|---|---|---|---|
| 0.0.0.7-beta4 | 2026-09-15 | 2 (versteht ab 1) | 2.1.0 | 8.2 / 5.0 – 7.1 | Formular-Baustein |
| 0.0.0.7-beta3 | 2026-09-15 | 2 (versteht ab 1) | 2.1.0 | 8.2 / 5.0 – 7.1 | Hintergrund-Aufgaben, Prüfabstand je Plugin, Durchoptimierung |
| 0.0.0.7-beta2 | 2026-09-12 | 2 (versteht ab 1) | 2.0.0 | 8.2 / 5.0 – 7.1 | Eine Leseabfrage je Request |
| 0.0.0.7-beta1 | 2026-09-12 | 2 (versteht ab 1) | 2.0.0 | 8.2 / 5.0 – 7.1 | Bibliothek mit Installation aus der Suite |
| 0.0.0.6 | 2026-09-12 | 2 (versteht ab 1) | 2.0.0 | 8.2 / 5.0 – 7.1 | Fassungs-Sperre beim Suite-Update, Dialog der Suite |
| 0.0.0.5 | 2026-09-12 | 2 mit Übergang von 1 | 2.0.0 | 8.2 / 5.0 – 7.1 | Übergangsschicht für Fassung 1 |
| 0.0.0.4 | 2026-09-12 | 2 | 2.0.0 | 8.2 / 5.0 – 7.1 | Backend in zwei Ebenen, mehrere Update-Server, Kanäle, Sicherungen, Import/Export, Migrationen, https-Pflicht |
| 0.0.0.3 | 2026-09-09 | 1 | 2.0.0 | 7.4 / 5.0 – 6.7 | Warnung vor Updates, die eine neuere Suite brauchen; Raster |
| 0.0.0.2 | 2026-09-09 | 1 | 2.0.0 | 7.4 / 5.0 – 6.7 | Suite für mehrere Produkte: Registry, Namensräume, SMTP, REST/AJAX |
| 0.0.0.1 | 2026-09-08 | – | 1.0.0 | 7.4 / 5.0 – 6.7 | Grundgerüst für ein einzelnes Plugin |
Core\Portal, Admin\AccountPage): neuer Reiter Suite → Kundenkonto, sobald in config.php eine Kundenplattform steht (portal_url). Die Anmeldung geschieht auf der Plattform – das Passwort des Kundenkontos wird in WordPress nie eingegeben. Der Weg dorthin ist die Browser-Rundreise nach OAuth 2.0 mit PKCE (S256): die Suite würfelt state und code_verifier, merkt beide zehn Minuten beim angemeldeten Benutzer, schickt den Browser zur Zustimmungsseite und tauscht den Einmal-Code danach Server zu Server gegen ein Token, das nur für diese Website gilt und nur drei Dinge darf: Lizenzen sehen, diese Website freischalten, Lizenzen beantragen. Für Agenturen dasselbe ohne Rundreise über einen Verbindungscode, den der Kunde in seinem Konto erzeugt. Das Token liegt verschlüsselt in den Einstellungen (Core\Crypto), geht nur in der Kopfzeile Authorization mit und ist vom Export ausgenommen. Angemeldet zeigt die Seite Konto, Website, Laufzeit, die Lizenzen des Kontos mit „Diese Website freischalten", die Produkte mit „Lizenz beantragen" und die offenen Anträge mit „Zurückziehen"; ein freigegebener Antrag wird beim stündlichen Abgleich selbsttätig übernommen – Schlüssel eintragen, beim Update-Server anmelden, Hinweis im Backend. Trennen wirkt auf beiden Seiten; eingetragene Lizenzschlüssel bleiben. Aktionen hit_wp_suite_portal_connected, hit_wp_suite_portal_disconnected und hit_wp_suite_portal_license_received.Core\Log, Core\LogChannel): Meldungen mit Stufen (debug, info, warn, error) in einer eigenen Tabelle statt im error_log, mit Bereich, Zusammenhang als JSON, Herkunft (Website, Backend, AJAX, REST, Cron, WP-CLI) und Benutzer je Zeile. Neuer Reiter Suite → Protokoll: Filter nach Plugin, Stufe und Suchwort, Zusammenhang zum Aufklappen, Herunterladen als Textdatei fürs Ticket, Leeren – ganz oder nach der Auswahl. Einstellbar sind die Stufe (Standard: Hinweise, Warnungen, Fehler), die Aufbewahrung (30 Tage), die Höchstzahl der Zeilen (5000) und ob zusätzlich ins PHP-Fehlerprotokoll geschrieben wird; gekürzt wird nachts von selbst. Ein Satellit schreibt mit $product->log()->warn('Bereich', 'Meldung', ['nr' => 42]), wer mithören will, hängt sich an die Aktion hit_wp_suite_logged; der Filter hit_wp_suite_log_entry kann eine Zeile ändern oder verwerfen, hit_wp_suite_log_level die Stufe übersteuern. Was im Zusammenhang nach Passwort, Schlüssel oder Token aussieht, wird durch *** ersetzt. Log::write() gilt unverändert weiter.Core\Schedule): wiederkehrende Aufgaben aller Produkte über ein Cron-Ereignis, das alle fünf Minuten nachsieht, was fällig ist. Anmeldung mit Schedule::register($product, 'name', ['interval' => 'daily', 'time' => '03:00', 'callback' => …]); Intervall als Name oder in Sekunden, Uhrzeit in der Zeitzone der Website (über die Zeitumstellung hinweg bleibt es dieselbe Uhrzeit). Dazu Wochentag (weekday, 0–7 oder 'mon' … 'sun' – macht die Aufgabe wöchentlich) und Tag im Monat (monthday, 1–31 oder 'last' – macht sie monatlich, und hat ein Monat den Tag nicht, gilt sein letzter: ein Monat fällt nie aus). Kommen die Angaben aus den Einstellungen, genügt das Ändern dort – der nächste Lauf wird sofort neu berechnet, ohne dass ein Plugin etwas anstossen muss. Je Aufgabe eine Sperre, ein Zeitbudget für den ganzen Lauf, gefangene Ausnahmen – ein Satellit kann den Cron nicht mehr zum Stehen bringen. Letzter Lauf, Ergebnis, Meldung und nächster Lauf stehen unter Suite → Aufgaben, dort auch „Jetzt ausführen" und „Aussetzen". Kein Plugin muss mehr selbst ein Ereignis eintragen, ein eigenes Intervall anmelden oder beim Deaktivieren aufräumen.Core\Cache): get, set, has, delete und remember() je Produkt, mit Gruppen, Vorgabe für die Lebensdauer (eine Stunde) und Obergrenze (30 Tage). Cache::flush($product) verwirft alles eines Produkts über eine laufende Nummer im Namen – auch mit Redis oder Memcached richtig, wo ein Löschen in wp_options nichts bewirkt. Im Gegensatz zu get_transient() lassen sich false, null und 0 ablegen und wieder unterscheiden; ein WP_Error aus remember() wird nie abgelegt.Core\Signature): der Update-Server signiert jedes Paket mit Ed25519 über Art, Slug, Version und SHA-256; die Suite prüft mit den öffentlichen Schlüsseln aus config.php (signing_keys) – bei jeder Update-Prüfung über die Nachricht, beim Einspielen über die selbst heruntergeladene Datei (upgrader_pre_download), beim Klick, beim automatischen Update, über WP-CLI und aus der Bibliothek. Betriebsart signature in config.php: off, warn (Auslieferung; unsigniert läuft durch, ungültig sperrt) oder require (ohne gültige Signatur wird nichts eingespielt, automatische Updates bleiben aus). Ergebnis je Produkt unter Suite → Updates („signiert · Schlüssel 6f976aa6", „der Server liefert keine Signatur", „Schlüssel … nicht hinterlegt", „Signatur ungültig – Update gesperrt") und als Sperrmeldung in der Plugin-Liste. Filter hit_wp_suite_signature_mode und hit_wp_suite_signing_keys. Die gemerkten Angaben (update_signature) sind vom Export ausgenommen. Der öffentliche Schlüssel des Update-Servers (6f976aa6) liegt in der config.php der Suite – er ist nicht geheim und für alle Installationen derselbe.ea) unter Suite → Updates, je Produkt: Fassungen mit -ea in der Nummer für einzelne Kunden, getrennt vom Beta-Kreis – auf ea nie eine Beta, auf beta nie Early Access. Der gespeicherte Wert geht wie bisher als channel mit jeder Metadaten-Abfrage; ein Wechsel prüft sofort. Ein Server, der ea nicht kennt, antwortet wie auf stable. UpdateChannel::EA, isEarlyAccess(), isPrerelease(), description(); die Erklärung unter der Auswahl gilt jetzt für Beta und Early Access.hit_wp_suite_log für das Protokoll. Sie entsteht beim ersten Aufruf des Backends von selbst; ein Update ohne erneute Aktivierung genügt.error_log schrieben, melden nun als Warnung (abgelehnte Anmeldung, unbrauchbare Angabe in config.php, Update-Server ohne https, veraltete Menü-Aufrufe, verworfenes Feld eines Formulars) oder als Fehler (gescheiterte Sicherung, abgebrochener Schritt einer Aufgabe, fehlgeschlagene Migration, gesperrtes Einspielen wegen der Signatur, fehlende Update-Bibliothek). Bei eingeschaltetem WP_DEBUG steht die Zeile wie bisher zusätzlich im PHP-Fehlerprotokoll – jetzt mit Stufe und Produkt davor.schedule_* (Stand der wiederkehrenden Aufgaben), cache_* (laufende Nummern des Zwischenspeichers) und portal_* (Verbindung zum Kundenkonto) aus – das ist Zustand, keine Einstellung, und eine Verbindung gehört zu genau einer Website.Einstellungsseiten schreibt kein Satellit mehr von Hand.
Admin\Form): Einstellungsseiten aus einer Felddefinition. Der Satellit meldet Karten und Felder an – achtzehn Typen (text, textarea, lines, number, toggle, select, radio, checkboxes, url, email, password, color, date, media, page, hidden, custom, note) –, die Suite gibt das Formular im eigenen Stil aus, nimmt es über eine gemeinsame admin-post-Aktion entgegen, prüft Nonce und Berechtigung, bereinigt je Typ, speichert in einem Rutsch, hinterlegt den Hinweis und springt zurück. Fehler stehen am Feld, die Eingaben bleiben dabei erhalten (Benutzer-Option, keine Transient). Dazu abhängige Felder (show_if), Passwort-Platzhalter mit Verschlüsselung, Medienauswahl über wp.media, Farbfeld, „Auf Standard zurücksetzen", eigene sanitize-/validate-/saved-Rückrufe, Aktionen hit_wp_suite_form_saved und hit_wp_suite_form_reset. Feldnamen sind die Schlüssel der Einstellungen – bestehende Werte bleiben beim Umstieg erhalten. Die Definition darf ein Rückruf sein, der erst läuft, wenn das Formular gebraucht wird.Product::addSettingsDefaults(), Array oder Rückruf, der erst bei Bedarf aufgelöst wird); get() kennt sie damit auch im Frontend und im Cron. Was bei der Anmeldung unter settings_defaults steht, hat Vorrang.data-hws-show-if).Hintergrund-Aufgaben, Prüfabstand je Plugin und die Durchoptimierung des Codes; Ausgabe und Rückgabewerte bestehender Bausteine unverändert. Schema 2.1.0.
Core\Jobs, Core\Job): Satelliten melden Langläufer als Aufgabe an und schreiben nur den Schritt; die Suite führt ihn über WP-Cron in Schritten mit Zeitbudget aus, merkt den Stand, setzt nach einem Abbruch dort wieder an und lässt je Produkt eine Aufgabe zugleich laufen. Jede Zeile wird per bedingtem UPDATE gesperrt; nach drei harten Abbrüchen hintereinander gilt die Aufgabe als gescheitert, eine Ausnahme im Schritt ebenso – jeweils mit Meldung. Ein Abbruch von aussen greift binnen zwei Sekunden auch mitten im Schritt. Solange Arbeit aussteht, hängt ein Fünf-Minuten-Ereignis als Netz; jede Nachfrage der Fortschrittsanzeige treibt die Aufgabe zugleich fünf Sekunden voran – auch mit DISABLE_WP_CRON. Baustein AdminPage::progress() zeigt Balken, Zähler und Meldung, das Skript schreibt ihn alle drei Sekunden fort; Abbrechen nach Rückfrage. Neuer Abschnitt Suite → Aufgaben mit allen Aufgaben, Abbruch, Löschen und „Jetzt bearbeiten"; beendete Aufgaben bleiben sieben Tage sichtbar, die Deinstallation eines Satelliten nimmt seine Aufgaben mit. Neue Tabelle hit_wp_suite_jobs (Schema 2.1.0); Aktionen hit_wp_suite_job_started/finished/failed/cancelled.config.php (update_check_hours, erlaubt 1, 3, 5, 6, 8, 10, 12, 16, 24, 48 Stunden; sonst 12, ungültige Werte landen im Protokoll). Ein geänderter Abstand setzt das Cron-Ereignis des Produkts neu an – die Bibliothek allein liesse das alte stehen. Filter hit_wp_suite_update_check_period. Unter Suite → Updates steht je Produkt der Abstand mit seiner Quelle, die letzte Prüfung und „Jetzt prüfen" – die Prüfung nennt eine bereitstehende Version, „auf dem neuesten Stand" oder den Fehler des Servers.Core\Log): Menu, Backups, Migrations, Updater, UpdateServers und Registry schreiben ihre Hinweise über Log::write($bereich, $meldung) statt über je eine eigene Kopie. Die Zeilen im Fehlerprotokoll sind unverändert ([HIT WP Suite] Update: …), weiterhin nur bei WP_DEBUG.Admin\AdminSection, intern): Lizenzen, Updates, Bibliothek, Import/Export und E-Mail erben url(), requireCapability(), requireProduct(), actionUrl() und die Datumsformatierung, statt sie je Klasse zu wiederholen. Öffentliche Methoden und Konstanten der Abschnitte unverändert.Product::basename() merkt sich das Ergebnis; UpdateServers::recordResult() liest die Antwort einmal statt zweimal; die Übersicht ermittelt den Lizenzzustand je Produkt einmal.update-servers.php; die Suite selbst prüft laut config.php alle drei Stunden.Plugin, AdminManager) ins Deutsche gezogen; Quellverweise der Übersetzungsvorlage nachgezogen (Strings unverändert).Menu::isOwnScreen() verglich den Slug als Teilstring des Haken-Namens und lud Stylesheet und Skript damit auch auf fremden Seiten, deren Kennung den Slug enthält (hit-a traf …_page_hit-alpha). Jetzt zählt das Ende _page_<slug>, so wie WordPress die Haken bildet.Leistung: Frontend-Requests von sechs auf eine Leseabfrage der Suite, Backend-Seiten von zehn auf eine – Ausgabe und Rückgabewerte unverändert.
Core\Settings): der erste Zugriff liest alle Namensräume mit einer Abfrage statt einer je Produkt; flushCache() lädt weiter gezielt, flushAll() erneuert den Vorrat.SHOW TABLES: die Schema-Option in wp_options belegt die Tabelle; tableExists(true) prüft weiterhin echt.Core\Installer): hit_wp_suite_db_version wird mit allen anderen Optionen geladen statt mit eigener Abfrage je Request; bestehende Installationen holen das einmalig nach.Core\UpdateServers): die update-servers.php eines Satelliten wird je Request einmal gelesen; Backups::dir() merkt sich die Ablage.activated_at, vom Export ausgenommen), die Hinweise von AdminNotice als Benutzer-Option je Website mit derselben Frist von 60 Sekunden. Vorher kosteten die fehlenden Transients vier Abfragen je Backend-Seite. Die Deinstallation räumt die Hinweise aller Benutzer ab.Settings::setMany() als ein Statement: ein INSERT … ON DUPLICATE KEY UPDATE für alle Schlüssel (Lizenzprüfung 4 → 1, SMTP speichern 13 → 1); dieselben Regeln wie set(), Zwischenspeicher erst nach Erfolg. seedDefaults() läuft darüber.Core\Library, Admin\LibraryPage): eine Karte je Plugin, das der Update-Server für die öffentliche Bibliothek freigegeben hat – Name, Symbol, Kurzbeschreibung, freigegebene Version, Voraussetzungen (WordPress, PHP, Suite-Fassung) und der Zustand auf dieser Website: nicht installiert · installiert, aber inaktiv · aktiv · Update verfügbar.activate_license), das Paket über <slug>.json erfragt und installiert. Der Schlüssel landet im Namensraum des Plugins – nach dem Aktivieren ist es sofort lizenziert und steht unter Lizenzen schon drin. Der Schlüssel reist nur in Kopfzeile und POST-Rumpf, nie in einer Adresse.hit_wp_suite_library_ttl).GET <server>/library.json (Format library: 1, Parameter domain, suite_version, suite_api, locale), abgefragt über dieselbe Serverliste mit Ausweichen wie die Update-Prüfung. Nur Einträge mit "public": true gelten – der Server liefert nur Freigegebenes, und die Suite verwirft zusätzlich jeden Eintrag ohne das Flag.data-hws-prompt*, hitWpSuite.prompt()); der Wert geht als verstecktes Feld mit dem Formular per POST mit.AdminPage::openCard() nimmt als Symbol auch eine Bild-Adresse (https) an; lädt das Bild nicht, wird es ausgeblendet.Core\SuiteGuard): nennt der Update-Server im Paket der Suite suite_api und supports_api_from, und braucht ein angemeldetes Plugin eine ältere Fassung, bleibt das Update der Suite sichtbar, wird aber gesperrt – beim Klick, beim automatischen Update und über WP-CLI (upgrader_pre_download, upgrader_pre_install, auto_update_plugin). Der Grund mit den betroffenen Plugins steht in der Plugin-Liste, auf der Update-Seite, auf der Übersicht der Suite und unter Suite → Updates. Wiederherstellen aus einer Sicherung bleibt möglich. Filter hit_wp_suite_block_update zum Übersteuern.HIT_WP_SUITE_API_SUPPORTED_FROM (derzeit 1): die älteste Fassung, deren Aufrufe die Suite noch versteht. Die Registry lehnt ein Plugin ab, dessen requires_api darunter liegt – mit Hinweis im Backend statt Fatal Error.assets/js/admin.js, auf <dialog>): ersetzt window.confirm(). Links und Absende-Knöpfe bekommen data-hws-confirm, -title, -ok, -danger; aus eigenem JavaScript hitWpSuite.confirm(). Skript-Handle Plugin::ADMIN_SCRIPT für Satelliten; ohne <dialog>-Unterstützung fällt es auf den Browser-Dialog zurück.update-servers.php und die Reihenfolge der Server ist entfernt; auf der Karte der Suite steht bei gesperrtem Update „Update gesperrt." mit Begründung.ü (doppelte Maskierung über esc_js(wp_json_encode())).Menu::addPage(), AdminPage::open($slug, $titel, $untertitel), Menu::url()/has() mit Seiten-Slug, AdminPage::registerTab()/removeTab()/tabs(), Menu::sorted()/registerTabs(). Alle sind als @deprecated markiert, melden sich über _deprecated_function()/_deprecated_argument() im Protokoll und entfallen mit Fassung 3.
'plugin' in den Argumenten oder Slug = Produkt-Slug).admin.php?page=<seite> bleibt als versteckte Seite erreichbar – Lesezeichen, „Einstellungen"-Link in der Plugin-Liste und Weiterleitungen funktionieren weiter; das Menü hebt das Produkt hervor.Menu::addSection() kennt 'tab' => false: ein Abschnitt ist erreichbar, erscheint aber nicht in der Reiterleiste (Detailseiten).Voraussetzungen ab hier: PHP 8.2, getestet bis WordPress 7.1.
Menu::addSection() an statt Seiten über Menu::addPage(); der Rückruf gibt nur noch den Inhalt aus – Kopf, Reiter und Rahmen macht die Suite. AdminPage::open() nimmt ein Array; Menu::sectionUrl(). Berechtigungen je Abschnitt; ein Produkt ohne sichtbaren Abschnitt erscheint nicht im Menü. (Die Aufrufe der Fassung 1 kamen mit 0.0.0.5 als Übergangsschicht zurück.)update-servers.php, Core\UpdateServers): Liste in Reihenfolge der Bevorzugung, je Produkt überschreibbar oder als eigene update-servers.php im Verzeichnis des Satelliten; Filter hit_wp_suite_update_servers. Antwortet ein Server nicht (Verbindungsfehler, 5xx, 404, 408, 429, ungültiges JSON), wird der nächste gefragt – bei der Update-Prüfung wie bei den Lizenzaufrufen; 401/403 gelten als Antwort. Die Server stehen bewusst in einer Datei, nicht in der Datenbank. update_base in config.php wird nur noch als Rückfall gelesen.Core\UpdateChannel): stable oder beta, geht als channel mit jeder Metadaten-Abfrage; ein Wechsel stösst sofort eine neue Prüfung an.Core\Backups): das laufende Plugin-Verzeichnis wird als ZIP unter uploads/hit-wp-suite/backups-<zufall>/ abgelegt (mit .htaccess und index.php), zwei Sicherungen je Produkt; Wiederherstellen und Sichern auf Knopfdruck.Admin\UpdatesPage): Kanal, Server mit Zustand der letzten Anfrage und Sicherungen je Produkt.Admin\SettingsTransfer) als JSON je Produkt oder gesamt, eigener Reiter. Lizenzschlüssel, Update-Zustände, Kanal, Sicherungen, Schemastand und SMTP-Passwort werden nie exportiert; Filter hit_wp_suite_export_exclude für Satelliten.Core\Migrations): nummerierte Schritte je Produkt, die die Suite beim ersten Request nach einem Update ausführt – in Reihenfolge, mit Sperre gegen Doppelläufe, Stopp beim ersten Fehler. Schemastand je Produkt in der Übersicht.config.php enthält nur noch Zweig und Token für Repositorien als Quelle.download_url aus den Metadaten. http wird abgelehnt; Ausnahme nur localhost und .test/.local für die Entwicklung (Filter hit_wp_suite_allow_insecure_update_url). Eine http-Download-Adresse wird verworfen – das Update bleibt sichtbar, wird aber nicht eingespielt.X-Hit-License-Key, nicht mehr als Query-Parameter; activate_license, check_license und deactivate_license gehen per POST.Rest\Ajax liest Parameter aus $_POST/$_GET statt $_REQUEST – ein Cookie kann keinen Parameter mehr überschreiben.license_key[<slug>]: Slugs mit - und _ konnten vorher auf denselben Feldnamen fallen.index.php in jedem Verzeichnis gegen Directory-Listing.Core\UpdateGuard): der Server nennt requires_suite_api in den Metadaten; die Suite warnt in der Update-Zeile der Plugin-Liste („Zuerst HIT WP Suite aktualisieren"), als Sammelhinweis auf Plugin- und Update-Seite und als gelbe Statuszeile auf der Übersicht. Bewusst keine Sperre.AdminPage::openGrid('forms')/closeGrid(), Karten über die volle Breite mit hws-grid__full.AdminPage::submit($label, $hinweis), die beim Scrollen am unteren Rand stehen bleibt; scrollbare Tabellen (hws-table-scroll).Vom Grundgerüst für ein einzelnes Plugin zur Suite für mehrere Produkte. Erste Fassung der Schnittstelle: HIT_WP_SUITE_API = 1. Schema 2.0.0.
Core\Registry, Core\Product): Plugins melden sich im Haken hit_wp_suite_loaded über Registry::register() an und nennen dabei requires_api; ist die Suite älter, lehnt sie ab und meldet es im Backend. Die Suite startet auf plugins_loaded mit Priorität 0, meldet sich selbst als Produkt an und schliesst die Anmeldung mit Registry::seal().plugin in der Einstellungstabelle (Schema 2.0.0), zwei Produkte dürfen denselben Schlüssel benutzen; vorhandene Zeilen werden der Suite zugeordnet. Der Installer kann die Spuren eines einzelnen Satelliten entfernen (uninstallProduct()).config.php steht statt einer Update-Adresse die Wurzeladresse update_base, daraus wird <Basis>/<slug>.json je Produkt; abweichende update_url bei der Anmeldung möglich.Admin\LicensePage) mit einer Karte je Produkt.Admin\Menu): Satelliten melden Seiten über Menu::addPage() an und bekommen Reiter und Stylesheet der Suite.Mail\SMTPMailer, Admin\SMTPSettingsPage) mit verschlüsselt abgelegtem Passwort und Testnachricht.Rest\Endpoint (Namensraum, Routen, Berechtigung, Antwortform) und Rest\Ajax (Nonce, Berechtigung, JSON-Antwort).uninstall.php: die Einstellungstabelle gehört allen angemeldeten Produkten – wird sie entfernt, sind auch deren Einstellungen und Lizenzschlüssel weg.Erste Fassung: Grundgerüst für ein einzelnes WordPress-Plugin. Voraussetzungen PHP 7.4, WordPress 5.0 (getestet bis 6.7); Schema 1.0.0.
Core\License): Schlüssel eintragen, prüfen, beim Server an- und abmelden.Core\ReleaseInfo): Sicherheitsupdate, Fehlerbehebung oder neue Funktion, sichtbar in der Plugin-Liste.<präfix>_hit_wp_suite_settings statt in wp_options (Core\Settings, Core\Installer mit DB_VERSION und Schema-Nachzug ohne erneute Aktivierung).Admin\AdminManager, AdminPage, AdminNotice).Core\Crypto), Core\Config mit Filter hit_wp_suite_config, Prüfung geforderter Fremd-Plugins (Dependencies\DependencyChecker, Filter hit_wp_suite_required_plugins), uninstall.php mit Option „Beim Löschen alle Daten entfernen".