Druckversion des Themas

Geschrieben von: Tiggr Mon. 20. August 2007, 20:37

Titel: Register User

Status: alpha

Version: 00.01.03

Sefrengo- Version: 1.4

Beschreibung:
Ein Formular im Frontend ermöglicht es dem Besucher der Seite einen Benutzer anzulegen. Dabei werden nur die nötigsten Informationen abgefragt.

Demo:
http://colorfulsky.co.ohost.de/index.php?idcatside=2

Features:
- Alle Formulare, Meldungen und Ausgaben voll konfigurierbar.
- Benutzer erhält eine Mail mit einem Bestätigungslink, erst wenn dieser aufgerufen wird, ist der neue User aktiv.

Autor(en): Marcus Ertl (aka Tiggr)

Lizenz: GPL

Dokumentation: Keine

Installation:
Das Modul wird einfach wie gewohnt in Sefrengo eingespielt.

ABER:
Die Datenbank ist ein bißschen zu erweitern. Dazu liegt eine kleine Datei bei, solange das Tabellenprefix cms_ ist, sollte sie ihren Dienst verrichten. Einfach mit 'mysql <datenbank> < update_users.sql' anwenden. Oder halt mit User und Passwort, und so weiter, oder gern auch über phpMyAdmin.

Vor der Modulinstallation muß die Datei 'class.SF_ADMINISTRATION_User.php' in 'backend/API/ADMINISTRATION' durch die im Archiv hinterlegte ersetzt werden. Sicherheitskopie nicht vergessen!

Die Änderungen sind mit Björn abgesprochen, er wird das ganze aber noch prüfen, und vielleicht auch verwerfen... (vgl. password_recover_hash)

To Do:
- mod_rewrite im Maillink berücksichtigen
- Zeilenumbruch in der Mail
- Blacklist für verbotene Usernamen (STam)

Testet das ganze bitte mal, ich hab es bisher nur im Testsystem ausprobiert...

Tschüss
Tiggr (aka Marcus)

Geschrieben von: summerbrother Mon. 20. August 2007, 21:18

Goil...

-Installation kein Problem
-Anmeldung funktioniert
-Bestätigungsmail kommt
-beim Bestätigungslink wird nur die Registrierungsseite aufgerufen, ohne Meldung mit leerem Formular, User ist nicht aktiviert.

Umgebung: SF 1.4, Modul läuft im 3. von 7 Projekten in der Installation, keine anderen Sprachen.

Und die Edith gleich hinterher:

Der Aktivierunglink funktioniert wegen dem "&" nicht, da in der Mail die URL mit "&amp;" ankommt.

Geschrieben von: Tiggr Mon. 20. August 2007, 22:43

Hiho!

Komisch, bei mir tut es auch mit &amp;, ich dachte das gehört so! Ich benutze Thunderbird und Firefox...

Ich änder das morgen! Dann hoffentlich auch mit mod_rewrite-Unterstützung im Mail-Link!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: bjoern Tue. 21. August 2007, 07:52

$sess->url() = mit &amp;
$sess->urlRaw() = ohne &amp;

Wie codiert das reinkommt (mit oder ohne &amp;) ist egal. Am Ende kommt es so raus, wie oben angegeben. &amp; ist bei XHTML Links wichtig, da es sonst einen Validierungsfehler gibt. In Mails funktioniert das nicht.

Geschrieben von: Tiggr Tue. 21. August 2007, 13:51

Hiho!

Falls heute Abend mein Internet läuft, gibts ne Fehlerkorrigierte Version! Wir stellen nur gerade um auf 16000 DSL...

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Tue. 21. August 2007, 14:22

Hiho!

Aha! Wieder was gelernt!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Tue. 21. August 2007, 19:27

Hiho!

Ganz nach "release early, release often", hab ich das erste Posting upgedatet: Eine Version, in der der Maillink korrekt formatiert ist, also ohne Entität, sondern mit &!

Was noch immer offen ist, ist die Übernahme von schönen mod_rewrite-URLs auch in die Mail!

Und in der Mail bekomme ich noch unschöne Leerzeilen, wohl ein Problem mit dem CR-LF, wie löse ich das Problem denn richtig?

Tschüss
Tiggr (aka Marcus)

Geschrieben von: summerbrother Tue. 21. August 2007, 19:42

Na supi,
klappt alles, Update sauber, Maillink perfekt, Anmeldung funktioniert, Aktivierung ok.
Gute Arbeit.

Ich wollt jetzt noch ein paar Felder (Name Vorname, etc.) für die Anmeldung hinzufügen.
Macht das Sinn, das ich mich in den Code einarbeite ?

Geschrieben von: Tiggr Tue. 21. August 2007, 19:52

Hiho!

Ich hab das erstmal bewußt einfach gehalten, damit ein anmeldewilliger User, der nur mal schnell einen Kommentar (mein nächstes Projekt) hinterlassen will, nicht gleich abgeschreckt wird.

Neue Felder aufzunehmen ist aber trotzdem einfach. Allerdings denke ich, da ist dann fast ein zweites Modul sinnvoll, in dem dann die Anmeldefelder gewählt werden können, und in dem Pflichtfelder gesetzt werden können.

Ich hab das so gesehen: Ich mach eine schnelle Anmeldung, und baue dann an den Stellen wo mehr gebraucht wird, entsprechende Abfragen ein.

Falls mal register_globals=off kommt, seh ich auch große Probleme mit meinem Code... :-(

OK, die Essenz dessen was ich sage ist: Sieh dir den Code mal an, ist verdammt einfach gehalten, und überleg dir, wie weit das sinnvoll erweiterbar ist. Ich denke, wenn du nur 2 Felder mehr brauchst ist das für ein individuelles Projekt schnell gemacht, ansonsten sollte man vielleicht was konfigurierbareres schreiben, mit einem flexibleren Ansatz!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: gunwalt Tue. 21. August 2007, 21:03

Ich habe mir das Modul noch nicht angesehen, aber mit mit nicht abgesicherten Schwachstellen zu arbeiten, halte ich für ungut.
Zu dem Thema ct 18/2007, S. 178ff.

Geschrieben von: Tiggr Tue. 21. August 2007, 21:31

Hiho!

Jaja, c't-Leser! ;-)

Nein, ernsthaft: So groß ist die Sicherheitslücke nicht! Die Gefahr ist ja, das du Variablen per URL setzt, die irgendwo im Code verwendet werden. Beispiel: Wir nehmen ja gern eine Variable $sql um unsere SQL-Statments zu bauen. Nun könnte ja wer auf die Idee kommen, da eine url der Art '...?sql=select * from cms_users;' abzusetzen. Und schon passieren ungute Dinge! Aber nur, falls du die Variable nicht vorher sauber initialisierst! Also vor der ersten Verwendung immer erstmal $sql='';! Fertig ist der Braten! Nun kann nichts mehr geschehen! Saubere Programmierung. Wer "richtige Programmiersprachen" gewohnt ist, declariert oder initialisiert seine Variablen eh!

So, das meine persönliche Meinung dazu!

Momentaner Stand bei Sefrengo:

Schau mal in die index.php, da wird diese Lücke extra wieder geöffnet und die globalen Variablen wieder bereit gestellt, falls das per register_globals=off verboten wurde:



Hab ich einfach aus der index.php übernommen! Also im Moment ist das noch so üblich bei Sefrengo, da hab ich mich danach gerichtet.

Die Roadmap sieht mit der Version 1.6 vor, das das genau anders wird, register_globals muss dann off sein!

Wie das ganze dann aussieht, keine Ahnung, ich denke mal, es wird dann eine API geben, um auf den REQUEST zuzugreifen, vielleicht reicht es auch auf die Variabel $_REQUEST auszuweichen.

Gibt es ja eigentlich jetzt schon, oder? http://wiki.sefrengo.org/index.php/Sefrengo_development_basics#Zugriff_auf_.24_GET.2C_.24_POST.2C_.24_COOKIE_Variaben

OK, das mit dem Zugriff auf die Variablen ist mir erst jetzt eingefallen! :-( Bau ich mal bei Gelegenheit um! Aber wie schon gesagt: Zur Zeit bin ich nicht unsicherer als Sefrengo an sich! Und ich denke Sefrengo ist so sicher oder unsicher wie die meisten CMS.

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Tue. 21. August 2007, 21:52

Hiho!

Noch schnell eine Version 00.01.02, keine Funktionalen Änderungen, oder irgendwas besonderes, ich hab mir nur die Kritik/Anregung von Guntram zu Herzen genommen: Das Modul sollte nun in Zukunft auch laufen, wenn register_globals=off gesetzt wird, und Sefrengo die register_globals=on auch nicht mehr simuliert! Wenn sich die API nicht ändert, ist es damit voll Sefrengo 1.6-tauglich!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: STam Thu. 23. August 2007, 12:48

Schöne Idee und Umsetzung,
hier nur ein paar Gedanken:

• es wäre wichtig das es im Backend eine Übersicht von User mit dem Flag 'Validierung ausstehend' gibt
• es wäre wichtig eine Art 'garbage control' zu haben die ausstehende Validierungen mit Ablaufdatum aufräumt - steht zwar im Modul-Text, habe ich dann wohl übersehen?
• es wäre wichtig eine Blacklist von Namen zu haben die nicht erlaubt sind
• schön wäre es wenn die Email-Check Funktion auch .info oder sonstige tld mit mehr als 3 Zeichen erlaubt - einfach die Regexp tauschen reicht leider nicht aus,
  da RFC822-Mailadressen eine relativ komplexe Syntax haben können. Die meisten Prüfungen auf der Basis einer einfachen Regexp lehnen viele legale Adressen ab
  (Es existieren zum Beispiel inzwischen gültige Toplevel-Domains mit mehr als 3 Buchstaben: .info, .name) und lassen zugleich ungültige Adressen zu.
  Es wäre doch viel einfacher (und dazu noch der SFway) wenn die in SF enthaltenen PEAR::Mail_RFC822 genutzt wird.
  Die kann das ehe schon alles (und viel besser) und das Modul ist frei von irgend welchem Fremdcode.
• schön wäre es wenn Funktionen innerhalb von Modulen auch im Namesraum des Modul bleiben, das check_exists() ist zwar schön und gut, jedoch bei Funktionsnamen wie 'check_email_mx()' erledigt sich das mit der vielfalt und der entsprechenden Benennung irgendwann von selbst - private Modul-Methoden sollten den Präfix mod_... haben!
• schön wäre es wenn das Modul (als optionale Komponente) keine Core Änderung nachsich zieht, eine Erweiterung/Vererbung der API-Klasse ADMINISTRATION_USER zu ADMINISTRATION_USER_REG hätte gereicht und macht später anderen Registrierungsformen (wie OpenId) den weg einfacher. Schließlich lebt die API von Erweiterungen/Vererbung und nicht von Änderungen.
• schön wäre es auch wenn das Modul eigene Tabellen-Felder auch in einer eigenen Tabelle definiert (grundsätzliche Core-Änderungen mal ausgenommen)!
• schön wäre es wenn das Modul ein Captcha anbietet
• schön wäre es wenn es optional schon bei Anmeldung einen User-Staus (mit eingeschränkter-Gruppe) gibt und nach freischaltung einen Full-Status (erweiterte/volle Gruppen-Rechte)

... oje, das soll nicht den Eindruck erwecken das ich das Modul schlecht finde, ich habe mich nur damit beschäftigt

...gut gemacht weiter so

Gruß

Geschrieben von: Tiggr Thu. 23. August 2007, 13:42

Hallo!

Vielen Dank erstmal für die vielen Anregungen! :-) Find ich nicht schlimm, ganz im Gegenteil!

Erstmal so vorweg: Ich programmier vor allem für den Eigenbedarf, und hoffe immer, dass es auch andere gebrauchen können, deswegen strebe ich nicht immer die flexible Allgemeinlösung an! Sorry - aber ich möchte mich da einfach nicht verrennen! Auch wenn es vielleicht etwas egoistisch ist!

OK, das sind eigentlich 2 Dinge, aber ich seh beide als Aufgaben des Backends an. (Dazu später noch mehr, bitte das ganze Posting lesen! ;-)) Ich weiß noch nicht, was da kommt. Entweder wird die nächste Version von Sefrengo sowas enthalten, oder ich werde über ein "Community-Plugin" nachdenken. Das muß ich mal mit Björn klären, weil vieles in diesem Modul ist auf die Idee von Björn hin so entstanden.



OK, gute Idee! Würde ich einbauen wollen. Gibt es irgendwo schon wo eine Liste, die man als Basis verwenden kann? (Rassistische Namen und ähnliches...)

Wo würde diese Liste denn verwaltet? Ich glaube sowas sollte zentral gepflegt werden, nicht im Modul, oder?



OK, einverstanden. Ich seh mir mal die PEAR-Klasse an! Kann aber einen Tick dauern! Dann fliegt auch wieder die Überprüfung der Domain per DNS raus, die macht mir etwas Bauchschmerzen...



Guter Punkt, und nur eine kleine Änderung, wird umgesetzt!

Mal so als dumme Frage für die Zukunft: Sollen man nicht vielleicht versuchen Module als Klassen zu bauen, um sie besser zu kappseln?



Volle Zustimmung!

ABER: Die Änderungen an den Tabellen und an der API sind auf Anregung von Björn entstanden, der mir zugesichert hat, das die Änderungen in die nächste Sefrengo-Version mit einfließen!

Mehr dazu unter: password_recover_hash, was ist das?

Hier muss Björn noch mal sagen, was von der Community-Funktionalität Core-Funktionalität werden soll, und was wir als Plugin realisieren sollen. Du hast ja ganz zu recht oben angemerkt, das im jetzigen Usermanagment noch nichts davon unterstützt wird.



Da hab ich mich bewußt dagegen entschieden, weil ich die Dinger für den Benutzer nur ätzend finde, ich glaubte, im Mailcheck genug Sicherheit zu haben. Natürlich kann ein Bot einen mit neuen Usern flooden, aber die werden dann ja (hoffentlich) nie aktiviert!

Ich würde auch nur sehr ungern Captchas einbauen... wie schon gesagt, ich find die Dinger sch....lecht!



Hmmm, find ich jetzt eher weniger sinnvoll , aber ich glaube das ist eine Zeile mehr im Frontend-Bereich des Moduls und ein mip-form mehr im Backendbereich. Kann ich machen!

Hab aber ein Problem: Ich brauch kurz Hilfe! Ich verwende im Backend



Um die Gruppenauswahl zu erzeugen! Ich habe es da noch nicht geschafft einen Eintrag "Keine Gruppe" rein zu bekommen! Das bräuchte ich dann nämlich sinnvoller Weise! Und ich will die mip-forms dafür nicht hacken!



Keine Angst, ich freu mich ja über jede Anregung, und vor allem darüber, das nicht umsonst gemacht zu haben. Ich hoffe es ist dann für dich auch ok, wenn ich mal bei dem einen oder anderen Punkt sage: Das will ich nicht! Wir sollten uns nur einigen, bevor wegen Kleinigkeiten 2 Module entstehen.

Tschüss
Tiggr (aka Marcus)

Geschrieben von: STam Thu. 23. August 2007, 14:33

Hiho,

vorweg

... ist schon klar. Ich respektiere deine Arbeit.

Ich finde es gut wenn Anregungen angenommen werden und der Dialog verbessert ja die Qualität des Modul/Code im hinblick auf eine breitere Nutzung.
Das mit den angekündigten Änderungen im Core schau ich mir an, hatte zwar im Hiterkopof eine zuletzt gegenteilige Meinung/Äußerung von Björn im Kopf
(... ja das war bei OpenId), doch das soll ja nicht schlecht sein. Ich hoffe nur das diese Erweiterungen maßvoll sind und nicht zuviel Funktionalität
in Core-Code übernommen wird, das schränkt nur die wiederwendbarkeit ein.

... guter Vorsatz, wurde shon mal angedacht. Ist für mich zur Zeit nicht Interessant,
mich interessieren eher Erweiterungen die auch im Business-Berech angewendet werden können. Dabei ist es grundsätzlich wünschenswert das es
Module/Plugins/Funktionalitäten gibt die (so wie die Registrierung) Dienste anbieten/realisieren. Zu diesen Diensten muss es vom Core natürlich definierte Schnittstellen geben (API)
die erweitert werden können. Dabei gilt die prämisse 'weniger ist mehr', es sollte kein verbauen sein sondern ein erweitern/anbieten.

Zur Blacklist, einfache Frage, (k)eine einfache Antwort; per CMS-Value. Einfach und gut pflegbar. Auch Erweiterungen/Änderungen über Modulupdates sind so möglich.

... gute Idee!

... Das mit den User-Rechten, ja genauso meinte ich das.
Im Modul schreibst du den User ja schon in die dB wenn er sich anmeldet. Zur Aktivierung wartet das Modul auf den Validierungs-Link.
Das wäre der Zeitpunkt wo man die Gruppe nachträglich ändern könnte. Dazu halt eine Mipform mehr (optional) 'Gruppe während der Anmeldung'/'Gruppen nach der Anmeldung'.
Ein 'Keine Gruppe' geht ja gar nicht

Gruß

Geschrieben von: Tiggr Thu. 23. August 2007, 15:53

Hiho!

Ich hoffe auch sehr, dass die Entwicklung da hin geht: Ein schöner, stabiler, schlanker Core, und viele, viele Erweiterungen in Plugins, damit man sich sein Traumsystem bauen kann!

Was sind für dich "Erweiterungen die auch im Business-Berech angewendet werden können"?

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Thu. 23. August 2007, 15:55

Und damit wir alles zusammen haben, ihr die Aussage von Björn zu den Datenbankfeldern:

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Thu. 23. August 2007, 18:13

Hiho!

Erster Kommentar: Ich hab mir die PEAR::Mail_RFC822 angesehen, mit dem Fazit: Die taugt für meinen Zweck nicht!

Die prüft wirklich ganz streng, ob eine Mail der RFC822 genügt, aber die Anforderungen sind nicht hoch genug, die an die Adresse sind nicht hoch genug, wir können ja nur eine Untermenge von gültigen Adressen gebrauchen.

So läßt PEAR::Mail_RFC822 die folgende Mail-Addi als gültig durch: fsdfasfs@fsdfsdfsf! Recht hat sie, nach reiner Logik haben wir eine Mailbox und einen Host angegeben, ist eine Adresse wie auch root@localhost, vollkommen zulässig also! Aber im Webbereich eher unglaubwürdig.

OK, also doch eine einfache Überprüfung per regex!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Thu. 23. August 2007, 18:59

Hiho!

Und eine neue Version!

- Ich hab die Funktion(en) sauber benannt, beginnen jetzt mit "mod_registerUser_"! Guter Hinweis, Danke!

- Es werden nun lange Toplevel-Domains aktzeptiert! Ich hab die Regex aus dem Kontaktformular geklaut, und TLDs bis 6 Zeichen erlaubt. PEAR::Mail_RFC822 hat sich leider als für die Anwendung wenig geeignet erwiesen!

- Ich hab die Überprüfung der Mail per DNS deaktiviert, war mir nicht sicher, ob das immer gut läuft, lieber mal eine falsche durchlassen, als gültige E-Mails aussperren.

- Jetzt ist es möglich, den neuen User schon vor der Validierung zu aktivieren, und ihm vor und nach der Validierung unterschiedlichen Gruppen zuzuweisen! :-)

- Offen bleibt die Blacklist für Namen! Nicht weil ich sie nicht will, ganz im Gegenteil, ich überlege nur, wie man das sinnvoll verwaltet. Außerdem weiß ich nicht, wie ich mit Variationen des Namens umgehen soll (unbedenkliches Beispiel): Mozart, Mozahrt, Mozzart, M0zart, m0z4rt, mohzarrt, ... da komm ich selbst mit phonetischem Vergleich nicht weit!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: Tiggr Sun. 9. September 2007, 14:35

Hiho!

Ich hab mal zum ausprobieren für euch eine Demo-Seite aufgesetzt: http://colorfulsky.co.ohost.de/index.php?idcatside=2

Tschüss
Tiggr (aka Marcus)

Geschrieben von: tobaco Mon. 10. September 2007, 07:10

schönes ding! danke.
könnte man auch noch leicht weitere eingabefelder hinzufügen und kann der nutzer sein profil später auch noch bearbeiten?

Geschrieben von: Tiggr Mon. 10. September 2007, 07:16

Hiho!

Leicht Eingabefelder zufügen ist leider nicht wirklich, ist gleich eine Codeänderung! :-( Ich hab das bewußt so minimal gehalten, damit der registrierungswillige Besucher schnell voran kommt. Ich wollte dann später die weiteren Daten abfragen, wenn sie gebraucht werden.

Zur Änderung des Profils wollte ich ein eigenes Modul schreiben, bin da aber noch etwas am Grübeln, wie es genau aussehen soll. Immerhin sollte man dann

- Eigene Felder anlegen können
- Felder zur Eingabe aus- und abwählen können
- Pflichtfelder setzen können

Tschüss
Tiggr (aka Marcus)

Geschrieben von: summerbrother Mon. 10. September 2007, 08:53

Ich benutze das RegisterUser zum selbst registrieren und aktivieren. Danach lasse ich die User mit http://forum.sefrengo.org/index.php?showtopic=1113
die eigenen Daten pflegen. Das Modul ist zwar nicht ganz sauber, aber vielleicht kann man darauf aufbauen. Ich denke im inetrenen geschlossenen Bereich ist das auch so zu verwenden.

Geschrieben von: Tiggr Mon. 10. September 2007, 15:56

Hiho!

Das Modul 'persönliche Daten' hatte ich ganz vergessen, ich seh mir das mal an...

Tschüss
Tiggr (aka Marcus)

Geschrieben von: bjoern Wed. 14. November 2007, 21:16

Hey Tiggr,

wie sieht es bei Dir nun mit dem Modul aus? Machst Du da noch weiter? Wenn Du noch vor hast ein stable Release vom Modul zu machen, dann prüfe und nehme Deine Coreänderungen in die SF 1.4.1 Version.

Geschrieben von: Tiggr Wed. 14. November 2007, 22:37

Hiho!

Klar geht es weiter damit, ich brauch es demnächst selber!

Hat denn schon wer Erfahrungen damit? Bei meinen Experimenten lief alles sauber, aber ich vertrau mir da nicht, ich weiß ja, was ich erwarte was passiert!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: summerbrother Wed. 14. November 2007, 22:57

Kann ich bestätigen. Läuft sauber, keine Probleme gehabt. Alles stabil.
In der Verbindung mit "persönliche Daten" eine klasse Sache. Vielleicht kann man die beiden Sachen noch zusammenpacken.

Geschrieben von: bjoern Wed. 14. November 2007, 23:06

Super! Also ich werde mir Deine Änderungen dann am Wochenende ganz genau anschauen und dann in den Kern übernehmen. Melde mich bei Dir, sobald es drin ist.

Geschrieben von: Tiggr Thu. 15. November 2007, 19:07

Super! Danke!

Dann könnten wir das Modul ja eigentlich auch in den stable-Bereich verschieben!

Tschüss
Tiggr (aka Marcus)

Geschrieben von: bjoern Thu. 15. November 2007, 20:53

Mach doch bitte einen neuen Thread auf, damit das keine (Topic-) Textwüste gibt.

Geschrieben von: FireFlyer Fri. 8. February 2008, 18:00

@Tiggr: fall es noch nicht geschehen ist (hab nichts gefunden) mach doch einen neuen Thread im Stable auf und lasse diesen ins Archiv wandern!

Geschrieben von: Gregor Fri. 13. February 2009, 22:56

Hallo Zusammen,

ich habe ein Problem mit Register User und sollte meine Nachricht hier fehl am Platz sein, dann sagt bitte Bescheid, dann lösche ich sie und erstelle separates Thema.

Ich habe Register User installiert und auch eingebunden und es scheint zu funktionieren, denn Benutzer werden in der Benutzerliste mit richtigen Grupperzugehörigkeiten angelegt und das Formular funktioniert auch korrekt, aber... es kommt keine Mail an bzw. wird keine gesendet (die Absende-EMail-Adresse existiert auf dem Server). Dann ist mir aufgefallen, dass ich die Datei 'class.SF_ADMINISTRATION_User.php' noch ersetzen sollte, was ich getan habe, aber keine Änderung - Mails werden nicht gesendet.

Ich weiß, dass das eine Alfa-Version ist, deswegen nur die Frage, ob Ihr wisst oder vermutet, wo ich anfangen sollte zu suchen bzw. was das sein könnte?

Sefrengo liegt in der Version 01.04.02 vor und Register User in der 00.01.03 und auf meinem Server (OpenSuSe) gab es noch keine Probleme mit Mail-Versand, auch nicht in anderen installationen von Sefrengo und z. B. Kontaktformular.

Ich hoffe Ihr könnt mir ein Tipp geben.

Danke schon mal im Voraus!

Viele Grüße!

Gregor

Geschrieben von: mvsxyz Fri. 31. July 2009, 17:53

Gibt es hierzu schon eine stable Version? Ich habe keine im Forum gefunden.

@Tiggr: Könntest du das ggf. nachholen? Danke schön.

Geschrieben von: leoboe Sun. 20. June 2010, 13:27

Hallo
Ich weiß dass der letzte Post in diesem Thread schon etwas länger her ist, allerdings habe ich ein Problem, was mit diesem Modul aufgetreten ist, und wollte nicht gleich einen neuen Thread dafür aufmachen.

Also: Seit ich das Register-Modul installiert und die Konfigurationen durchgeführt habe erscheint nach dem Login nur noch die Fehlermeldung:

Ich habe schon versucht, die Änderungen des Moduls wieder rückgängig zu machen, das Ergebnis war das gleiche.
Auch bei der Frontent-Ansicht bekomme ich einen ähnlichen Fehler

Das auch auf dem Server laufende MyBB-Forum läuft ganz ohne Probleme.

Da mir mein Hoster auch nach Support-Anfrage keinen Zugriff auf die php.ini oder nur auf die maximale Memory-Größe erlaubt hoffe ich nun dass ich das Problem irgendwie so lösen kann.

In dem System installierte Module: (ich hoffe die Liste ist vollständig ich kann ja im Moment nicht nachsehen )
-WYSIWYG2
-Pic-Galerie
-Random-Pic
-Twitter
-Listen-Navigation (2x)
-Content-Flex
-Gästebuch
-Frontend-Login
(-Register-User)

Plugins:
-Artikelsystem

Falls noch irgendwelche Informationen fehlen schreib ich sie noch dazu.