Skip to content

FAQ

FG Core stellt die gemeinsame WordPress-Admin-Infrastruktur für eingebettete FUNCKGROUP-Plugins bereit. Dazu gehören Plugin-Registrierung, ein gemeinsames Admin-Menü, optionale Tabs, Runtime-Auswahl und eine technische Installations-Statusmeldung.

Ist FG Core ein eigenständiges WordPress-Plugin?

Section titled “Ist FG Core ein eigenständiges WordPress-Plugin?”

Die eigentliche Runtime ist als eingebettete Library konzipiert und wird unter includes/fg-core/ mit FUNCKGROUP-Plugins ausgeliefert. Das vorliegende Repository enthält zusätzlich FG Core Dummy als installierbares Referenz- und Funktionstest-Plugin.

Muss Composer auf der WordPress-Installation vorhanden sein?

Section titled “Muss Composer auf der WordPress-Installation vorhanden sein?”

Nein. Composer ist im Projekt nur für den Entwicklungs- und Sync-Workflow vorgesehen. Die ausgelieferte Runtime wird direkt aus includes/fg-core/ geladen.

Was passiert, wenn mehrere Plugins unterschiedliche FG-Core-Versionen enthalten?

Section titled “Was passiert, wenn mehrere Plugins unterschiedliche FG-Core-Versionen enthalten?”

FG Core sammelt die eingebetteten Kandidaten und startet die höchste verfügbare Version. Bei gleicher Version entscheidet zunächst die höhere API-Version und danach der Provider-Name.

Kann ein Plugin mehrere Verwaltungsbereiche registrieren?

Section titled “Kann ein Plugin mehrere Verwaltungsbereiche registrieren?”

Ja. Über tabs können mehrere Bereiche mit Titel, Callback, Capability und Sortierposition registriert werden. Ohne Tabs kann eine einzelne Seite über callback bereitgestellt werden.

Welche Berechtigung verwendet FG Core standardmäßig?

Section titled “Welche Berechtigung verwendet FG Core standardmäßig?”

Für das Hauptmenü und für Plugin-Registrierungen ist standardmäßig manage_options vorgesehen. Plugins und einzelne Tabs können eigene Capabilities verwenden; die Hauptmenü-Capability ist über einen Filter anpassbar.

Sendet FG Core Daten an einen externen Server?

Section titled “Sendet FG Core Daten an einen externen Server?”

Ja. Die aktivierte Installations-Statusmeldung sendet per WP-Cron technische Installations- und Plugin-Metadaten an den konfigurierten Status-Endpunkt. Details zu allen Feldern stehen unter Installations-Statusmeldung.

Kann die Statusmeldung deaktiviert werden?

Section titled “Kann die Statusmeldung deaktiviert werden?”

Ja. FG_CORE_STATUS_REPORTING kann auf false gesetzt werden. Zusätzlich existiert der Filter fg_core_status_reporting_enabled.

Setzt FG Core Cookies oder verwendet LocalStorage?

Section titled “Setzt FG Core Cookies oder verwendet LocalStorage?”

Nein. Im aktuellen Projektcode werden weder Cookies gesetzt noch localStorage verwendet.

Registriert FG Core REST- oder AJAX-Endpunkte?

Section titled “Registriert FG Core REST- oder AJAX-Endpunkte?”

Nein. Version 1.1.3 registriert keine eigenen REST-Routen und keine WordPress-AJAX-Actions. Die Statusmeldung ist ein ausgehender HTTP-Request.

Die Statusmeldung speichert Installations-ID, Installationstoken, gebundene Home-URL sowie Diagnoseinformationen zum letzten Versand in WordPress-Optionen. Das Referenz-Plugin speichert zusätzlich seinen Beispielwert in fg_core_dummy_example_text.

Was passiert bei Deinstallation des Referenz-Plugins?

Section titled “Was passiert bei Deinstallation des Referenz-Plugins?”

Die mitgelieferte uninstall.php löscht nur fg_core_dummy_example_text. Die gemeinsamen fg_core_*-Statusoptionen und ein geplanter Status-Cronjob werden durch diese Datei nicht entfernt.

Nein. Die WordPress-Runtime lädt vorhandene PHP- und CSS-Dateien, lädt aber keine neue Core-Version aus GitHub und ersetzt keine Plugin-Dateien. Das getrennte Entwicklungswerkzeug tools/sync-fg-core.php kann vor einem Release den eingebetteten Runtime-Ordner ersetzen.