IDF Home

Changelog

v2.4.0

Hinzugefuegt

• idf_home_get_license_key() und idf_home_has_license() als Public API. Plugins, die den Lizenzschluessel selbst brauchen, holen ihn jetzt ueber IDF Home statt ueber get_option(). Anlass: idf-pdf-thumbnail las idf_master_key_license_key, also den Namen aus der Master-Key-Zeit. Seit v2.0.0 heisst die Option idf_home_license_key, und wo IDF Home direkt als 2.x eingerichtet wurde, hat die alte nie existiert - die Remote-Erzeugung meldete dort einen fehlenden Schluessel, obwohl das Dashboard ihn als gueltig auswies (k1.de). Der Rueckfall auf den alten Namen steckt in der Funktion, damit genau eine Stelle die Migration kennt und sie mit v3.0.0 zusammen mit den uebrigen BC-Wrappern verschwindet.

v2.3.0

Hinzugefuegt

• Eine Plugin-Aktivierung kann die Website nicht mehr lahmlegen. Neuer Load Guard (includes/class-load-guard.php): nach jeder Aktivierung, Deaktivierung, Loeschung und jedem Update wird der Opcode aller IDF-Checker-Dateien verworfen. Der naechste Request kompiliert sie in der jetzt gueltigen Ladereihenfolge neu, wodurch ein class_exists-Guard wieder greift, statt von einer frueh gebundenen Kopie im OPcache uebergangen zu werden. Greift auch bei Aktivierungen ueber die WordPress-Plugin-Liste und bei Updates ueber MainWP.
• Selbsttest nach der Aktivierung mit Ruecknahme. Installiert oder aktiviert IDF Home ein Plugin, prueft es die Website danach per Loopback auf die REST-Wurzel. Antwortet sie mit einem Serverfehler, wird das Plugin still wieder deaktiviert und die Meldung samt Fehlertext angezeigt, statt den Nutzer auf einer weissen Seite stehen zu lassen. Kommt gar keine Antwort, bleibt alles unveraendert - ein Netzwerkproblem darf kein funktionierendes Plugin abschalten.
• Hintergrund: Auf k1.de hat am 03.09.2026 zweimal die Aktivierung eines IDF-Plugins die ganze Website lahmgelegt. Ursache war die geteilte Klasse IDF_Dependency_Checker, die fast alle IDF-Plugins mitbrachten. Alle Plugins tragen inzwischen plugin-eigene Klassennamen; der Load Guard schuetzt zusaetzlich Seiten, auf denen noch aeltere Plugin-Versionen liegen.

Geaendert

• Die mitgelieferte Vorlage includes/class-dependency-checker.php deklariert IDF_HOME_Dependency_Checker statt des geteilten Namens und stellt die Klasse in einen bedingten Block. IDF Home laedt diese Datei selbst nicht; sie ist die Vorlage, aus der neue Plugins kopieren.

v2.2.3

Behoben

• Die Seitenleiste blieb auf den Tiefseiten zugeklappt. Die beiden Filter aus v2.2.2 konnten das nicht richten: menu-header.php ruft sie auf und direkt danach get_admin_page_parent(), und die setzt $parent_file als Nebeneffekt neu. Die Tiefseiten hängen jetzt unter dem echten Eltern-Menü idf-home und werden erst auf admin_head mit remove_submenu_page() wieder aus der Navigation genommen (reiter_ausblenden()). Dort ist der Hook bereits aufgelöst und die Seitenleiste noch nicht gerendert - die Seiten sind unsichtbar, über ihre URL erreichbar, und das Menü klappt auf. Der versteckte Eltern-Slug idf-home-reiter entfällt damit.
• parent_file und submenu_file bleiben registriert: submenu_file markiert den Eintrag, parent_file ist die Rückfalloption für Screens, die get_admin_page_parent() gar nicht erst in $submenu findet.

v2.2.2

Behoben

• Auf den Reiter-Seiten blieb die Seitenleiste zugeklappt und kein Eintrag war markiert. Beim Arbeiten in Einstellungen, Hilfe oder Deinstallieren war nicht zu sehen, in welchem Plugin man überhaupt ist. Ursache ist die Menüstruktur seit v2.2.1: die Seiten hängen an idf-home-reiter, einem Eltern-Slug ohne Menü, und genau den liefert get_admin_page_parent() dort auch zurück - WordPress findet kein Menü, das es aufklappen könnte. Zwei Filter (parent_file, submenu_file) korrigieren das jetzt auf idf-home, solange wir auf einer eigenen Seite stehen. Auf fremden Seiten wird der durchgereichte Wert unverändert zurückgegeben.

v2.2.1

Behoben

• Die Tiefseiten waren per URL nicht mehr aufrufbar und antworteten mit „Sie haben nicht die Berechtigung, auf diese Seite zuzugreifen". Ursache war remove_submenu_page(): es löscht den Eintrag aus $submenu, und genau dort sucht WordPress beim Direktaufruf über get_admin_page_parent() den Eltern-Slug, um den Hook-Namen zu bilden. Ohne den Eintrag fällt der Name auf admin_page_... zurück und passt nicht mehr zu dem, unter dem der Callback hängt. Die Seiten hängen jetzt an einem Eltern-Slug, den es als Menü gar nicht gibt (idf-home-reiter) - dadurch stehen sie nirgends in der Navigation und bleiben trotzdem erreichbar.
• Gefunden beim Smoke-Test: die Reiter selbst funktionierten, der Aufruf einer Seite über ihre eigene URL nicht.

v2.2.0

Geändert

• IDF Home ist jetzt die Heimat aller IDF-Plugins in der Navigation. Jedes Plugin hängt sich mit genau einem Eintrag hier ein, statt ein eigenes Top-Level-Menü aufzumachen. 43 Top-Level-Menüs hatten die WordPress-Seitenleiste unbenutzbar gemacht.
• Die eigenen Seiten sind Reiter statt Menüpunkte. Einstellungen, Hilfe und Deinstallieren bleiben unter ihren bisherigen URLs erreichbar, stehen aber nicht mehr in der Navigation - sonst stünden sie gleichrangig neben den Plugin-Namen.

Hinzugefügt

• Die eingehängten Plugin-Einträge werden alphabetisch sortiert (sort_submenu(), admin_menu Priorität 999). Ohne das hängt die Reihenfolge an der Plugin-Ladereihenfolge und ändert sich, sobald ein Plugin dazukommt.

Beachten

• Plugins müssen sich mit admin_menu-Priorität 20 einhängen. IDF Home baut sein Menü mit der Standard-Priorität auf; wer früher kommt, findet kein Eltern-Menü und landet nirgends.
• Der Reiter für die DSGVO-Pflichtseite fehlt noch, weil die Seite selbst noch fehlt (#50, #51). tabs() ist die einzige Stelle, an der er dann ergänzt wird.

v2.1.0

Behoben

• Auf einer Betreiber-Domain fehlten die internen Plugins im Dashboard. Der Katalog wurde per wp_remote_post bei der eigenen Seite abgeholt. Dieser Server-zu-Server-Aufruf trägt weder Origin noch Referer, und genau daran entscheidet der Key-Server die Whitelist. Die eigene Seite kam dort als fremde Kundenseite an und bekam den öffentlichen Katalog.

Geändert

• Läuft der Key-Server im selben WordPress, fragt IDF Home ihn direkt (idf_kse_get_catalog(true), Key-Server ab v2.2.0) statt über HTTP. Nebenbei fällt ein sinnloser HTTP-Umweg zu sich selbst weg.

Beachten

• Die Weiche hängt an IDF_Home_Helper::is_whitelisted_domain(), also an der eigenen Site-URL. Das ist eine Aussage über sich selbst und nicht fälschbar; ein Header wäre es gewesen.
• Für Kundenseiten ändert sich nichts. Ohne lokalen Key-Server bleibt es beim bisherigen HTTP-Weg mit Lizenzschlüssel.
• Der Katalog-Cache bleibt bestehen (idf_home_plugin_catalog, 6 h). Nach dem Update zeigt das Dashboard den alten Stand, bis jemand auf „Katalog aktualisieren" klickt oder die Zeit abläuft.

v2.0.1

Behoben

• Fatal Error bei paralleler Aktivierung mit altem idf-master-key (Cannot redeclare function).
• Andere IDF-Plugins zeigten „IDF Master-Key 1.5.0 fehlt"-Notice, sobald das alte Plugin deaktiviert war.

v2.0.0

Geändert (Breaking)

• Plugin umbenannt: idf-master-key → idf-home. Folder, Klassen, Konstanten, Funktionen, CSS-/JS-Prefixes, Hooks, Optionen und Logfile-Pfade entsprechend migriert (Schließt #19, #24, #27, #40).
• WordPress sieht das nach dem Update als neues Plugin - einmalige manuelle Reaktivierung pro Kundeninstanz nötig.

Hinzugefügt

• Backwards-Compat-Layer für alte idf_master_key_*-Funktionen, Filter und Optionen (Entfernung in v3.0.0 geplant).
• Options-Migration läuft beim ersten Aktivieren automatisch.

v1.5.7

Behoben

• idf-external-image im Dashboard sichtbar gemacht.

v1.5.6

Hinzugefügt

• Dashboard-Plugins in 3 Tabs (Aktiv | Deaktiviert | Nicht installiert) mit Anzahl-Badges.

v1.5.5

Behoben

• Self-Update-Reaktivierung scheiterte bei Updates aus Versionen < v1.5.4.

v1.5.4

Behoben

• Self-Update deaktivierte Master-Key dauerhaft.

v1.5.3

Hinzugefügt

• Website-Link pro Plugin-Karte im Dashboard.

Behoben

• Lizenz-Status auf Einstellungsseite blieb auf „Pruefe..." hängen.

v1.5.2

Behoben

• Plugin blieb nach Update via Master-Key deaktiviert.

v1.5.1

Hinzugefügt

• Server-Erreichbarkeitsprüfung, Self-Update-Health-Check und Operations-Log-Viewer im Dashboard.
• Dirname-Mismatch-Warnung auf Plugin-Karten.

Geändert

• Doppelter HTTP-Request beim Update-Check eliminiert.

v1.5.0

Hinzugefügt

• Zentraler IDF_Master_Key_Plugin_Manager (Singleton) mit einheitlichem 7-Schritt-Ablauf für alle Plugin-Operationen.
• Master-Key kann sich selbst aktualisieren (Self-Update via /health-Endpoint und download_url).
• Datei-basiertes Operations-Log mit .htaccess-Schutz und 500 KB-Rotation.

v1.0.0

Hinzugefügt

• Initiale Version als „Ideenfabrik Base"-Skeleton.