[PHP] BugReporter v0.1

[Florian Hämmerle]

Hallo alle zusammen!

Da ich im Moment gerade dabei bin, Lösungen für eine erfolgreiche Teamarbeit zu suchen, hab ich mich mal an den PHP-Editor gesetzt und angefangen zu tippen. Raus gekommen ist ein kleiner

BugReporter

Funktionen:

• BugReports erstellen
• BugReports editieren
• BugReports löschen
• Passwort nötig für diese Funktionen

Alles was für den BugReporter nötig ist, ist PHP und SQLite (ist bei neueren PHP-Versionen schon integriert).
Der BugReporter verwendet für zwei kleine Spielereien jQuery (ist aber für die Funktionalität nicht von Bedeutung).

Wer Lust hat, kann es sich ja mal anschauen. Ich hab vor, den BugReporter noch etwas auszubauen.
Was ich in nächster Zeit vorhabe:

• User-Handling einfügen (damit nicht immer die Passwort-Eingabe notwendig ist)
• Rollen für Team-Mitglied und Administrator
• BugReport-Status (offen, in Arbeit, Erledigt)
• Suche
• Erstell-Datum und Änderungs-Datum speichern
• RSS-Feed, damit man über Änderungen über dem laufenden bleibt (Alternative zu E-Mail-Benachrichtigung)
• Admin-Kontrollzentrum

Wer Ideen für weitere Features hat, bitte melden, ich werde versuchen, diese so weit wie möglich einzubauen.

Florian
alcaeus hat mich auf Sicherheitslücken aufmerksam gemacht. Ich werd diese erstmal ausmerzen und dann erst wieder einen Download anhängen.

[mirage228]

Muss ich SQLite noch zusätzlich installieren?

Derzeit bekomme ich lokal mit PHP 5.2 unter IIS 7.5 diese Meldung

Zitat:

Fatal error: Class 'SQLiteDatabase' not found in C:\inetpub\wwwroot\bugreporter\common.php on line 29

Edit: Ah, mit PHP 5.3 unter XAMPPLite geht es. Weitere Kommentare folgen :mrgreen:

Viele Grüße

[Florian Hämmerle]

ab PHP5 ist SQLite eigentlich standardmäßig dabei :S

Zitat:

SQLite ist, als Alternative zu MySQL, seit PHP 5.0 in PHP enthalten.

mfg Florian

[Florian Hämmerle]

Liegt es vielleicht daran, dass du XAMPPLite hast? Ich hab n "ordentliches" XAMPP bei mir auf dem Rechner und dort funktioniert es wunderbar.

Schöne Grüße,
Florian

[mirage228]

Mit XAMPPLite und PHP 5.3 habe ichs doch noch hinbekommen.

Also bisher gibt es ja noch nicht soo viel zu sehen, aber an sich wäre ich für mich persönlich auf jeden Fall an so einem einfachen Bugtracker interessiert, der nicht so komplex für kleinere Projekte ist, wie z.B. Mantis.

Was mich aber noch etwas verwirrt, dass beim Erstellen, Bearbeiten und Löschen-Dialog die Beschriftungen der Felder fehlen. Das sieht besonders beim Hinzufügen etwas seltsam aus... (Drei unterschiedlich große, leere Felder und ein Speichern-Button).

[Florian Hämmerle]

Zitat:

Zitat von mirage228 (Beitrag 1028539)

Mit XAMPPLite und PHP 5.3 habe ichs doch noch hinbekommen.

Also bisher gibt es ja noch nicht soo viel zu sehen, aber an sich wäre ich für mich persönlich auf jeden Fall an so einem einfachen Bugtracker interessiert, der nicht so komplex für kleinere Projekte ist, wie z.B. Mantis.

Was mich aber noch etwas verwirrt, dass beim Erstellen, Bearbeiten und Löschen-Dialog die Beschriftungen der Felder fehlen. Das sieht besonders beim Hinzufügen etwas seltsam aus... (Drei unterschiedlich große, leere Felder und ein Speichern-Button).

Ja das war auch mein Antrieb, einen eigenen kleinen zu schreiben.
Beschriftung der Felder werd ich noch hinzufügen. *work* werd den Anhang sofort mit dem neuen ersetzen.

mfg Florian

[mirage228]

Ah gut, das bringt schon mal etwas Licht ins Dunkel.

Damit sich Dein BugReporter aber noch etwas mehr als solcher bezeichnen kann, fände ich folgende Funktionen wichtig:

• Bug-Status (wie schon oben von Dir angemerkt)
• Datum des Bug-Reports, damit ich solche ggf. chronologisch abarbeiten kann
• User-Handling (wie auch von Dir schon genannt), damit auch Benutzer / Gäste ggf. Bug-Reports einstellen können
• Zu letzterem: E-Mail Benachrichtigung bei neuem Bug-Report von User

Und noch zwei Details zur Oberfläche:

• Im Löschen-Dialog wird nur von "diesem" Bugreport gesprochen. Wenn man nicht gerade auf die ID in der Adressleiste achtet, weiß man nicht unbedingt was man gerade löscht
• Beim Bearbeiten / Hinzufügen / Löschen - Dialog fehlt jeweils Header und Footer der Seite

Viele Grüße

[Florian Hämmerle]

Danke für die Hinweise.

Header und Footer hab ich da bisher extra weggelassen, aber hat schon seine Berechtigung, falls man mal auf die Seite gerät ohne dass man es eigentlich will. Werd ich in den kommenden Tagen noch erledigen.
Zu den anderen Hinweisen:

• E-Mail-Benachrichtigung: Ist sicher ein nettes Feature, aber für einen kleinen BugReporter wie ich ihn machen will glaub ich nicht nötig. Dann mach ich da glaub ich lieber ein RSS-Feed, dass Interessierte dann abonnieren können.
• User-Handling: Ich hab mir das so vorgestellt, dass sich Mitglieder registrieren können und vom Administrator freigeschalten werden müssen. Dann können sie direkt BugReports verfassen und editieren. Löschen kann nur der Administrator (kann auch mehrere Administratoren geben). Gäste können auch BugReports verfassen, diese müssen aber noch von einem Mitglied oder Administrator freigeschalten werden (in der Zwischenzeit, also von der Erstellung bis zur Freischaltung, sind sie als 'nicht-sicher' markiert.). Um aber nicht von irgendwelchen Bots heimgesucht zu werden, wird dann auch für Gäste eine "are you human?"-Abfrage nötig werden.
• Datum des Bug-Reports: werd ich auch noch einbauen --> date_create, date_edit, dann hat man beide Datum für die Suche.
• Für die leichtere Handhabung des ganzen (falls es mal mehrere BugReports werden ist es sehr umständlich jeden einzeln zu löschen) werd ich dann auch ein Administrator-Kontrollzentrum bauen, in dem man eine Liste der BugReports hat, und dort schnell mehrere gleichzeitig als erledigt markieren kann oder löschen.

Danke erstmal fürs Testen,
Florian

[alcaeus]

Ganz kurz und buendig: SQL-Injection. In 5 deiner 4 Datenbank-Funktionen. Das ist das kritische.
Dazu kommt: die Anwendung ist ohne technische Ueberlegung aufgebaut. Nach ein paar zusaetzlichen Features hast du 200 PHP-Dateien, wovon 10 functions_* heissen und mindestens 30 Funktionen enthalten. Wie willst du da noch den Ueberblick behalten?
Weitere Punkte: Templating-System ist nicht nur nicht vorhanden, sondern auch sehr ungeschickt geloest (wenn du die HTML-Ausgabe im PHP-Code zusammenstellst kannst du dort auch die PHP-Tags schliessen und den HTML-Code direkt hinschreiben. Datenbanktechnisch bist du voll auf SQLite fixiert. Die Verwendung eines Abstraction Layer (PDO) laesst dich da unabhaengiger sein und verringert das Risiko solcher brachialer Sicherheitsluecken (Prepared Statements).

Wenn du ernsthafte PHP-Anwendungen entwickeln willst, vergiss den Ansatz den du getroffen hast. Mach dich uebers MVC-Konzept schlau, informier dich ueber diverse MVC-Frameworks und guck mal was die fuer dich machen koennen. Mein Favorit ist immer noch Symfony 1.4 mit Doctrine. Da wird das Ganze schon etwas interessanter: Datenbank-Abstraktion, klare Trennung von Logik und View, Logik in Models gekapselt, ein Test-Framework fuer Unittests, usw.

Nimms mir nicht uebel, aber ich wuerde dir dringends raten, den Download aus dem ersten Beitrag erstmal wegzunehmen und nochmal ueber die Applikation nachdenken.

Greetz
alcaeus

[Florian Hämmerle]

Ich hab nicht vor, das Ding groß zu machen. Es ist eigentlich nur für mich gedacht. Wer es brauchen kann, kann es sich gerne ziehen und damit machen was er will. Speziell für dich: kannst es gerne runterladen, entpacken und in den Papierkorb verschieben.

Ich hab auch nie gesagt, dass der Code absolut sicher ist, oder sich an irgendwelche Styleguides hält. Was PDO anbelangt: Ich hab mich für SQLite entschieden, weil es eben sehr einfach gehalten sein soll. Es kann auch sein, dass ich an der Struktur, wie sie jetzt ist, nochmal alles ändere. Es geht mir nicht darum nen perfekten BugReporter zu basteln, sondern etwas kleines, was ich brauchen kann. Ob es jemals noch wer anderer verwendet ist mir eigentlich egal.

Und wenn ich ernsthaft PHP-Applications schreiben möchte, würde ich mich nicht in nem DELPHI-forum sondern in nem PHP-Forum melden ;).

Schöne Grüße,
Florian

PS: Trotzdem werd ich mir deine Hinweise (SQL Injection, Templates, etc) zu Herzen nehmen.