MFI Example Page

Eine vollständige, lauffähige Website. Sie holt selbstständig Wetterdaten, lässt daraus den Mähbarkeitsindex berechnen und zeigt das Ergebnis an – mit Empfehlung im Klartext, Indexwert und den Begründungen der einzelnen Prüfungen. Es ist kein Baukasten und kein Plugin für ein bestehendes System, sondern ein fertiger Satz Dateien, den du auf deinen eigenen Webspace legst. Wie das Ergebnis aussieht, zeigt das laufende Beispiel unter mep.maehbarkeitsindex.de.

Für die Vorlage selbst fallen keine Kosten an. Der Zugang zur MFI API ist kostenfrei, ebenso der benötigte OpenWeather-Zugang in dem hier genutzten Umfang. Bezahlen musst du nur dein eigenes Webhosting, sofern du noch keines hast.

Du solltest Dateien auf einen Webspace hochladen können und wissen, wo du im Kundenmenü deines Hosters eine Datenbank anlegst. Programmierkenntnisse sind für die Einrichtung nicht nötig – der Assistent führt durch alle Schritte und prüft jede Eingabe. Für eigene Erweiterungen sind PHP-Grundkenntnisse hilfreich.

Wenn beide Zugangsschlüssel bereits vorliegen und die Datenbank angelegt ist, sind es meist 15 bis 30 Minuten. Rechne zusätzlich Wartezeit für die Schlüssel ein: MFI-Zugangsschlüssel werden von Hand freigeschaltet, neue OpenWeather-Schlüssel brauchen einige Stunden, bis sie funktionieren.

Nötig sind PHP ab Version 8.2, eine MySQL-Datenbank ab 8.0 oder MariaDB ab 10.4 und ein Apache-Webserver. Diese Angaben stehen in der Leistungsübersicht deines Hosters. Im Zweifel lade die Dateien einfach hoch: Der erste Schritt des Einrichtungsassistenten prüft die Umgebung und sagt dir genau, was fehlt.

Ein API-Key ist ein Zugangsschlüssel – eine lange Zeichenfolge, mit der sich deine Website bei der MFI API ausweist. Du beantragst ihn kostenlos über das Registrierungsformular. Nach der Bestätigung deiner E-Mail-Adresse wird der Schlüssel von Hand freigeschaltet. Bewahre ihn wie ein Passwort auf.

Ein Cronjob ist eine zeitgesteuerte Aufgabe, die der Server regelmäßig von selbst ausführt – hier alle 15 Minuten das Abrufen neuer Wetterdaten. Bietet dein Hosting keinen Cronjob, gibt es zwei Alternativen: die Betriebsart „beim Seitenaufruf", bei der die Daten erneuert werden, sobald jemand die Seite besucht, oder ein externer Cron-Dienst, der eine tokengeschützte Adresse deiner Website aufruft.

Der DocumentRoot ist das Verzeichnis, dessen Inhalt dein Webserver nach außen sichtbar macht. Idealerweise zeigt er auf den Ordner public/, damit Konfiguration und Programmcode gar nicht erst erreichbar sind. Lässt sich das bei deinem Hoster nicht einstellen, verschiebst du den Inhalt von public/ in dein Webverzeichnis und die übrigen Ordner eine Ebene darüber; in zwei Dateien ist dann ein Pfad anzupassen. Die mitgelieferte Serverkonfiguration sperrt vorsorglich auch dann den Zugriff auf Konfigurations-, Datenbank- und Protokolldateien.

Nein. Du kannst alle Dateien per FTP hochladen und die Einrichtung vollständig im Browser erledigen. Ein Shell-Zugang ist nur bequemer, wenn du das Projekt per Git aktuell halten oder die Wartungsbefehle direkt aufrufen möchtest.

Voreingestellt sind 15 Minuten. Kürzere Abstände sind nicht sinnvoll: Die MFI API lässt pro Zugangsschlüssel standardmäßig nur alle 300 Sekunden eine Berechnung zu und antwortet sonst mit einer Fehlermeldung. Zusätzlich begrenzt die Vorlage die Wetterabrufe auf 200 pro Tag, damit du nicht versehentlich in die Grenzen des kostenfreien Zugangs läufst.

Der kostenfreie OpenWeather-Zugang liefert keine Bodentemperatur und keine Bodenfeuchte. Ohne diese Werte überspringt die MFI API den Bodencheck und weist die Datenqualität als „teilweise" aus. Die Vorlage blendet den Check deshalb standardmäßig automatisch aus – das ist kein Fehler, sondern gewolltes Verhalten.

Langzeitwerte wie die Regenmenge der letzten 14 Tage berechnet die Vorlage aus ihren eigenen gespeicherten Läufen. Diese Historie muss sich erst aufbauen. Ein abgeleiteter Wert wird erst gesendet, wenn das jeweilige Zeitfenster zu mindestens 80 Prozent belegt ist – die längeren Fenster kommen also nach und nach dazu.

Ja, das ist vorgesehen, erfordert aber PHP-Kenntnisse. Die Wetterquelle steckt hinter einer klar abgegrenzten Schnittstelle: Du legst eine eigene Klasse im Ordner für Wetterquellen an und trägst sie in der Übersicht der verfügbaren Quellen ein. Mit einer eigenen Station stehen dann meist auch Bodenwerte zur Verfügung, sodass alle fünf Prüfungen laufen und die Datenqualität steigt.

Nicht ohne Anpassung. Die Vorlage ist bewusst auf einen Standort ausgelegt, damit sie übersichtlich bleibt. Die Datenbank führt allerdings bereits eine Standortkennung mit, sodass eine Erweiterung möglich ist.

Ja. Farben und Abstände änderst du über eine eigene Stylesheet-Datei, die nach dem mitgelieferten Design geladen wird; eine kommentierte Vorlage mit allen Variablen liegt bei. Ein eigenes Logo trägst du in der Konfiguration ein, alle sichtbaren Texte stehen gesammelt in einer Sprachdatei. Beachte dabei: Sobald du Farben ersetzt, gelten die nachgemessenen Kontraste nicht mehr automatisch – du musst sie dann selbst prüfen.

Nein, nicht automatisch. Alle Angaben zu WCAG 2.2 AA, Kontrasten, Bedienbarkeit ohne Maus und Verzicht auf Cookies und externe Ressourcen beschreiben den Auslieferungszustand der Vorlage. Sobald du Farben änderst, eigene Seiten und Bausteine ergänzt, Schriften von einem fremden Server einbindest oder Analyse- und Kartendienste, Videos oder Social-Media-Elemente hinzufügst, gelten sie für diese Teile nicht mehr. Die Verantwortung für Barrierefreiheit und Datenschutz deiner Website liegt bei dir als Betreiber.

Ja. Deine eigenen Seiten, dein Kopf- und Fußbereich, deine Gestaltung und deine Konfiguration liegen in Bereichen, die von der Versionsverwaltung ausgenommen sind. Die mitgelieferten Gegenstücke dürfen sich bei Updates weiterentwickeln, ohne deine Fassung zu überschreiben. Eine Ausnahme gibt es: Ersetzte Kopf- und Fußbereiche erhalten künftige Verbesserungen der Vorlagen nicht automatisch mit.

Hast du per git clone installiert, genügen im Projektverzeichnis git pull und anschließend der Prüflauf php bin/check-setup.php. Ohne Shell-Zugang lädst du die neue Fassung als ZIP von der Releases-Seite herunter und überträgst per FTP nur die Verzeichnisse src, bin, install, pages-default und public. Nicht überschreiben darfst du config.php, pages, partials, var und public/assets/css/user-style.css – diese Bereiche gehören dir. Ein Blick in die CHANGELOG.md vor dem Update zeigt, was sich geändert hat. Ausführlich steht das alles im Abschnitt Aktualisieren weiter oben.

Ja, vollständig. Du kopierst die gewünschte Vorlage aus src/templates/partials in das Verzeichnis partials und bearbeitest sie dort; ab dann verwendet die Website ausschließlich deine Fassung und behält sie auch nach einer Aktualisierung. Möglich ist das für header.php, footer.php und badge.php. Das ist zugleich der Ort für Links auf Seiten, die nicht in der Hauptnavigation erscheinen sollen, etwa Impressum und Datenschutzerklärung. Welche Hilfsmittel darin bereitstehen, beschreibt partials/LIESMICH.md.

In aller Regel ja – beides ist für den Betrieb einer Website meist verpflichtend. Die Vorlage liefert die Texte bewusst nicht mit, weil sie von Rechtsform, Hosting und eingesetzten Diensten abhängen. Du legst die Seiten wie jede andere eigene Seite an und lässt die Texte im Zweifel rechtlich prüfen.

Im Auslieferungszustand nicht. Es gibt kein Tracking, keine externen Schriftarten und keine eingebundenen Fremdinhalte – alle Dateien liegen auf deinem Server. Ein einziges technisches Cookie wird während der Einrichtung gesetzt, um den Assistenten vor fremdem Zugriff zu schützen. Deine Website selbst ruft im Hintergrund OpenWeather und die MFI API auf; für deine eigene Datenschutzerklärung ist das relevant. Ergänzt du später eigene Dienste, ändert sich diese Einschätzung entsprechend.

Ja. Es gelten die Nutzungsbedingungen der MFI API; unter anderem ist die Quelle anzugeben. Das mitgelieferte Badge im Fußbereich der Vorlage erfüllt diese Anforderung bereits, weitere Varianten stehen im Styleguide bereit.

Erste Anlaufstelle ist das mitgelieferte Diagnosewerkzeug, das Umgebung, Datenbank, Erreichbarkeit der API und Schreibrechte in einem Durchlauf prüft und Probleme konkret benennt. Bleibt eine Frage offen, helfen die Diskussionen und der Issue-Tracker des Projekts weiter. Fragen zur API selbst beantwortet die API-FAQ.