Mailer-Project Community

Hallo zusammen,

ich habe da eine Idee. Bei den letzten Commits habt ihr vielleicht gesehen, dass die Erweiterung events dazu gekommen ist. Diese soll bei eintretenden Ereignissen, diese einfach für das Mitglied zum Nachvollziehen loggen. Ich könnte jetzt überall beigehen und dies mit:

if (EXT_IS_ACTIVE("events")) {
 LOG_EVENT("some_event", $userid);
}

zum Beispiel erledigen. Dies ist mir aber etwas zu unflexible. Und was ist, wenn auf das selbe Ereignis eine weitere Erweiterung einen Funktionsaufruf haben möchte. Dann muss ich sie mit ähnlichem if()-Block dazufügen.

Hier käme ein Ad-Hook System in Frage. Bei der Registrierung oder Update der Erweiterung müsste einfach die Erweiterung ihren Funktionsnamen auf das jeweilige Ereignis registrieren - ein weiterer Kandidat dafür ist removeip - und beim Entfernen der Erweiterung wieder deregistrieren. Beim Registieren wird ein Eintrag in der Datenbank gespeichert und beim Deregistrieren wieder entfernt.

Dadurch bräuchte dies ewige Registrieren und Deregistrieren von Funktionen - man sagt dazu auch Call-Back-Funktionen - nicht bei jedem Seitenaufruf getan werden, sondern "nur" bei der De-/Installation der jeweiligen Erweiterung.

Ich glaube, dies ist auch die performanteste Lösung - ein starres Array kann hier ja nicht in Frage kommen, eher cachen.

Was haltet ihr von der Idee? Ich würde natürlich weitere ähnliche Stellen umbauen auf das Ad-Hook-System - z.B. die Adminwillkommensseite.

VG,
Quix0r

Hallo,

Leider kennt ja PHP keine events nativ und man muss sich eine solche Events-Klasse zusammenbasteln, was aber relativ leicht ist in PHP. Werde mal bei Zeiten eine solche events-Klasse zusammenbastln. Seit ich C# angefangen habe proggen habe ich das schon vor.

MfG
Stelzi

Hmmm, mir fällt da höchstens noch die SPL (Standard Programming Library) ein, dieses bietet einen Observer/Subject an und dieser ist auch in C++ geschrieben. Damit ist er zwar performanter als die reine PHP-Implementation, mein Script hängt dann aber davon ab, ob diese auch aktiviert ist. Und ich meine, sie steht nur ab PHP v5 zur Verfügung und MXChange soll PHP v4 noch kompatibel sein.

Ab 0.3.0 allerdings wird nur noch PHP 5.1+ unterstützt, ohne Rücksicht auf PHP4 Installationen.

Ich hoffe, die Klasse, die du mir zugesandt hast, war jetzt nicht nur für MXChange? Ich habe nämlich eine klassenlose Implementierung in's Auge gefasst. Dies sollte unter PHP4 weniger Ärger machen...

Natürlich ist diese Art der Programmierung (Revision 635 enthält dies; siehe inc/filters.php) vollkommen veraltet. Aber PHP4 ist es auch.

Wie bereits mehrmals hier geschrieben: Ab 0.3.0 wird alles ab PHP 5.1 laufbar sein, PHP4 wird dann gar nicht mehr unterstützt. Natürlich werden da "viele" bei 0.2.1-FINAL hängen bleiben, aber vielleicht können diejenigen es sich gut überlegen, ob sie noch eine veraltete Serversoftware behalten wollen oder mal langsam umsteigen wollen.

0.2.1-FINAL läuft übrigens auch auf 5.1.

Ich würde ja (wie bereits in einer Mail angeführt) in 0.2.1-FINAL nicht mehr was neues einbauen und nur mehr BugFixes machen. Hauptaugenmerk auf 0.3.0 und wenn da was brauchbares da ist in 0.2.1-FINAL nur mehr wichtige Security-Fixes machen und End of Support ankündigen. So wird an keinem System rumgebastelt, was eigentlich sowieso schon veraltet ist.

PHP4 wurde schon ca. vor einem knappen Jahr im Prinzip kalt gestellt. Wer jetzt noch nicht umgestellt hat stellt ohnehin so schnell nicht um und der wird auch wahrscheinlich nur wegen der neuen 0.3.0 nicht umstellen. Ein Hoster der nicht auf PHP5 umstellt, den fressen ohnehin bald die Konkurenten, wenn er am alten PHP4 festhält.

Verstehe ohnehin nicht, warum noch so viele aktiv für PHP4 entwickeln.

PS: 0.2.1-FINAL läuft übrigens auch auf 5.2.

Oh, suppi (das mit 5.2), ich habe hier auch 5.2, upps...

Okay, was meinst du zu folgendem:
http://forum.mxchange.org/topic-288.html
Und auch: (nur Erweiterungen)
http://forum.mxchange.org/topic-380.html

Ich denke, ich sollte die klaffende Baustelle nicht so lassen, bevor 0.3.0 angegangen wird.

Hast du ein Bugtrackersystem im Einsatz? Ich benutze da http://www.mantisbt.org/
Das hat Änderungsprotokoll (Changelog), Roadmap und Zusammenfassung alles schön Übersichtlich. Alles öffentlch einsehbar kann jeder den Verlauf des Projektes einsehen. Für vertrauenswürdige Bugfixer kann dann ein Account zum Reporten und Fixen eines Bugs gemacht werden. Keine wilde Struktur wie in einem Forum mehr.

Ja, habe ich hier installiert. Nur leider nutzt es kaum einer. Die meisten posten doch im Forum.

Jo war mir nicht bekannt --> warscheinlich, weils nirgendwo erwähn wird. Hab bis jetzt nicht gewusst, dass du ein Mantis hast. Werde mich da mal anmelden.

Ähm jo Anmeldung funzt nicht. Es wird kein Capatcha angezeigt.

PS: Xdebug auf einem Produktivserver ausgeben lassen ist auch nicht so die beste idee.
PPS: Nen E_Strict auf nem Produktivserver ausgeben lassen sollte man auch lassen.

Ich stelle ja die Sachen die noch geproggt werden sollen als FeatureRequest rein. So kann ich auch tracken wann ich die fertig habe und was noch gemacht werden muss.

PS: Wennst ErrerReporting zumindest für Mantis ausblendest sollte das Capatcha wieder angezeigt werden. Das script sendet da einen E_Strict vor der Ausgabe des Bildes.

Upps, sollte ich mal auf die "Produktiv-PHP.INI umstellen"

Okay, ist umgestellt. Danke für den Tipp.

PS: Ich habe auf meinem Server zwei php.ini: Eine php.ini.work (kein Debugging an) und php.ini.debug (alles was möglich ist für's "Live-Debugging" eingeschaltet.

Ich brauche somit nur den symbolischen Link umbiegen und den Apache neustarten. Fertig.

Also ein Sticky mit dem Link zum Bugtracker zumindest im Supportforum währe hilfreich. Besteht die Möglichkeit, dass da noch überhaupt keine Bugs(FeatureRequests) drinnen sind? Sämtliche noch nicht erledigte Punkte wie http://forum.mxchange.org/topic-288.html und http://forum.mxchange.org/topic-380.html sollten dort rein.

Die SVN-Commitlogs dann als News rein und schon sieht jeder die Aktivität.

Hmmm, dann müsste ich die Commitlogs per Hand oder per RSS-Feed einbinden? So sehr kenne ich Mantis nun auch nicht.

Okay, das mit dem Sticky mache ich kurz, gute Idee! Die beiden von dir genannten Postings werde ich mal nach dort verlagern.

Auch jeden der einen Supportthread erstellt hat bei einem Bug bitten diesen ins Bugsystem einzutragen, dann wird das Bugsystem schon promotet.

Ps: Mantis hat eine automatik eingebaut zum closen von Bugs per Commit-Log --> aber das nur sehr rudimentär und relativ kompliziert zum einbauen.

Hab das mal in meine Signatur getan. Okay, habe dort einiges an den Versionen und Kategorien geändert. Auch habe ich die Projekte aktualisiert.

jo habs schon gesehen, aber jeder Punkt sollte seinen eige Bug# haben. Hm lässt du die Roadmap ausblenden oder warum wird dort nix angezeigt?

Wundert mich auch. Kannst ja als Bug einstellen. Nein, Scherz. Wo kann man diese einschalten? Und wieso steht dort 100% bei Issue Status Percentage?

Naja hab selber jetzt lange rumgesucht. Eigentlich Logisch wenn mans betrachtet.
Eine Roadmap, kann man ja nur von einer Version haben, die noch nicht veröffentlicht wurde. Einfach bei der Projektverwaltung unter Versionen den Haken bei veröffentlcht weckmachen und schon wird eine Roadmap angezeigt. Ich benutze bei mir daheim ja die 1.2er developer-Version -> da sind ein paar sachen anders.

Noch eine Idee der String "Please report this error at forum.mxchange.org:" bei Fehlermeldungen sollte auch auf den Bugtracker umgebogen werden.

Okay, werde ich gleich mit erledigen.