Bugs und Fehler berichten

This page is a translated version of the page Filing bugs and issues and the translation is 100% complete.

Um im Joomla! Bugtracker einen Bug zu berichten, eine Trackermeldung erstellen. Danach prüfen Entwickler dessen Gültigkeit und handeln entsprechend. Wer testen helfen will: Wie man Joomla!-Patches testet.

Bugs berichten

Ein Konto auf GitHub erstellen

Man muß auf Github ein Konto anlegen; der Joomla! Issue Tracker verwendet GitHub-Konten zur Authentifizierung.

Im Joomla! Issue Tracker anmelden

Joomla! Issue Tracker- Öffnen

Prüfen, ob der Bug schon berichtet wurde

Eine Reihe von Filtern zeigt die Tracker-Elemente an. Die Filter können durch Klicken auf die Schaltfläche "Search Tools", die sich über der Liste befindet, aufgerufen werden. Wenn das Problem nicht bereits gemeldet wurde, bitte auf die Schaltfläche "New Item" im Hauptmenü klicken.

Im angezeigten Formular die Informationen eingeben, je klarer sie sind, umso einfacher ist es für die Entwickler.

So viele Informationen als möglich eingeben. Tipps für jedes Feld werden angezeigt, wenn in "Ansicht" auf der rechten Seite von "Pro" auf "Hilfe" umgestellt wird.

Priorität : Den Standard "Medium" wählen, außer man kennt den Code genau genug für eine andere Wahl.
Version: Die vom Problem betroffene(n) Version eingeben.
Kategorien: Das ist anspruchsvoll. Im Zweifelssfall "Administration" wählen.
Titel: Kurze Zusammenfassung des Problems.
Beschreibung: Details des Problems. Weitere Informationen dazu in den Abschnitten unterhalb.
Uploads: Bilder können in Problemmeldungen verwendet werden. Detailinformationen dazu im Berichtformular.

Zusammenfassung bereitstellen

In wenigen Worten das Problem beschreiben. Für Einsteiger sind existierende Problemmeldungen Beispiele zum Lernen.

Beispiele::

Frontend: Warnung dies und jenes
Backend: Beitrag lässt sich nicht speichern, wenn "NamedesPlugin" veröffentlicht ist.

Anmerkung: Die Zusammenfassung präzise schreiben, das sie das Erste ist, das Entwickler beim Durchsuchen des Trackers lesen, wenn sie Probleme zum Lösen suchen.

Details zum Bug bereitstellen

Um viele sinnvolle Informationen zu bekommen, ist das Beschreibungsfeld in fünf Abschnitte geteilt.:

Steps to reproduce the issue: Detaillierte Schritte, wie eine andere Person das Problem reproduzieren kann.
Expected result: Was passieren soll, wenn die oben beschriebenen Schritte durchgeführt werden.
Actual result: Was wirklich bei den angeführten Schritten passiert.
System information: Wie das verwendete System konfiguriert ist. Welcher Browser, welche PHP-Version, welcher Datenbanktyp sind gemeint. Optimal sind die Informationen im Backend unter "System > Systeminformationen".
Additional comments: Nützliche Informationen zur Fehlersuche und Problembehebung, die noch nicht gegeben wurden.

Die grundsätzliche Beschreibung soll ähnlich Folgendem sein:

"Das habe ich exakt getan."
"Das ist passiert."
"Das sollte meiner Meinung nach passieren."
"Weitere Information, mögliche Lösung, vorgeschlagener Codepatch."

Je mehr Details, umso besser. Das Problem soll mit einer Joomla-Standardinstallation inklusive Beispieldateien oder mit klaren Anweisungen des Setup reproduzierbar sein. Andere haben keine Möglichkeit, eine problematische Datenbank zu testen, deswegen muß ihnen klar mitgeteilt werden, wie sie ein Problem repoduzieren können - die Website mit Beispieldateien.

Beispiele A

Das habe ich gemacht: Anmeldung an der Website mit Beispieldateien, alles war ok. Dann habe ich das "NamedesPlugin" veröffentlicht. Im Backend versucht, einen Beitrag zu speichern.
Was passierte: Ich erhielt eine leere Seite, der Beitrag wurde nicht gespeichert.
Was passieren sollte: Der Beitrag sollte korrekt gespeichert werden.
Weitere Informationen: Die Liste der ebenfalls veröffentlichten Plugins. SEF ist ein (oder aus). Die Site ist in einem Unterverzeichnis. Weiters möchte ich anmerken, dass ... etc. Die Dateien soundso sind meiner Meinung nach das Problem weil (Gründe angeben).

Beispiele B

Das habe ich gemacht: Anmeldung im Backend, auf das Menü "Menüname" klicken.
Was passierte: Das öffnende Fenster ist leer.
Was passieren sollte: Das Menü sollte korrekt geöffnet werden.
Weitere Informationen: Alle anderen Menüs arbeiten ok, etc.

Tatsächlich geschehenes Beispiel

Das habe ich gemacht

Anmeldung im Backend der Website mit Beispieldateien
Ein versteckten Beitrag im Backend mit Sektion=FAQ und Kategorie=Generell hinzugefügt.
In den erweiterten Parametern des Beitrages "Titel enzeigen" auf "Nein" und Drucken, PDF und E-Mail-Symbole auf "Verbergen" gestellt.
Beitrag gesichert und Fronend aufgerufen. Anmeldung als Administrator, Beispielseite -> Kategorieblog-Menüeintrag aufgerufen.

Was passierte: Der neu angelegte Beitrag wird angezeigt, allerdings ohne "Bearbeiten"-Symbol für Frontend-Benutzer.
Was passieren sollte: Das "Bearbeiten"-Symbol wird angezeigt, Frontend-Benutzer können den Beitrag bearbeiten.
Weitere Informationen: Das passiert nur imrhuk_milkyway-Template. Wird der Code [Code-Vorschlag] der Datei [Name und Hierarchie der Datei], Zeile(n)# geändert, ist das Problem mit meinen Einstellungen gelöst.

Fix direkt im Github-Repositorium von Joomla einbringen

Einen Fix mit Code direkt in Joomla vorzuschlagen erfolgt mit einem "Pull Request" im Code-Repositorium von Joomla! auf GitHub.com: https://github.com/joomla/joomla-cms

Der Prozeß benötigt Wissen über "Source Control Management-Systeme" und Git im speziellen. Es ist einfach, wenn man über dieses Wissen verfügt:

Registrierung für ein kostenloses GitHub.com-Konto
Das Joomla!-Repo forken
Zum "Staging"-Branch wechseln, wenn der Fix die aktuelle 3.x-Veröffentlichung betrifft oder zu einem anderen Branch wechseln, wenn der Fix für eine zukünftige Joomla-Version vorgesehen ist.
Die betroffenen Dateien im richtigen Branch ändern oder hinzufügen, den "review & compare"-Button anklicken, um den "Pull Request"-Prozess zu starten (weitere Informationen unter https://help.github.com/articles/using-pull-requests).

Extra Tipps und Tricks

Gut geschriebene Bugberichte sind sehr hilfreich. Allerdings gibt es eine bestimmte Menge an Mehrarbeit in jedem Bug-Trackingsystem. Jede Hilfe, den Tracker verwendbar zu halten, ist willkommen. Im Speziellen:

Die FAQ lesen, ob das Problem bereits wohlbekannt ist.
Den Tracker durchsuchen, ob das Problem bereits gemeldet ist.
Im Forum Bugbericht fragen, ob das Problem wirklich ein Bug ist.
Bugberichte sollen komplett, reproduzierbar und speziell sein. Soviele Informationen wie möglich schreiben, komplettiert mit Codeteilen, Test-Szenarien, etc. Ein kurzes Beispiel, das den Bug in einem einfachen Testszenario illustriert, ist der bestmöglich Bugbericht.
Das Trackersystem ist nicht für Supportfragen da. Dafür gibt es das Joomla!-Forum.
Das Trackersystem ist nicht für umfangreiche Funktionswünsche da. Größere Änderungen am Joomla!-Core werden im Entwickler-Forum diskutiert, bevor daran gearbeitet wird.
Berichte, die als "Erwartetes Verhalten" markiert sind, nicht wieder öffnen. Die Markierung bedeutet, dass das Problem nicht gefixt werden kann oder soll. Bei Unklarheit im Entwickler-Forum nachfragen.
Das Trackersystem ist nicht für langatmige Diskussionen da, sie gehen wahrscheinlich verloren. Führt eine Trackermeldung zu kontroversiellen Diskussionen, sind sie im Entwickler-Forum zu führen.

Sicherheitsprobleme berichten

Sicherheitsprobleme an security [at] joomla [dot] org berichten. Die private Liste ist nur für langandauernde und zuverlässige Joomla!-Entwickler geöffnet, das Archiv ist nicht öffentlich zugänglich.

Im Fall einer bestätigten Schwachstelle in Joomla! selbst wird dies unternommen:

Bestätigung an den Berichter, dass der Report erhalten wurde und ein Fix bevorsteht. Es wird eine ungefährer Zeitplan gegeben und der Berichter um Vertraulichkeit gebeten, bis der Fix angekündigt ist.
Pausieren aller anderen Entwicklungsarbeit bis der Fix geschrieben ist, inklusive Patches im aktuellen und zwei vorhergehenden Veröffentlichungen.
Bestimmen einer öffentlichen Ankündigung der Schwachstelle und des Fix. Um ein mögliches Wettrennen zwischen denen, die den Patch anwenden und denen, die die Schwachstelle ausnutzen wollen zu vermeiden, werden Sicherheitsprobleme nicht sofort verkündet.
Öffentliche Ankündigung der Schwachstelle und des Fix an einem vorher bestimmten Datum. Das ist vermutlich eine neue Veröffentlichung von Joomla!, manchmal einfach nur ein Patch im aktuellen Branch.