- Sende Willkommensnachricht? JA/NEIN
- Standard Sprache für Willkommensnachricht [Auswahlliste]
- Willkommens Nachricht versender [Auswahlliste]
Die 60 Sekunden in den Einstellungen im Admin- Bereich vielleicht dann hier reinpacken.
Also das:
Private Nachrichten der Benutzer regelmässig abfragen:
Bei diesen stellt sich die Frage, ob wir diese nicht dort lassen wo sie jetzt sind oder dort total rausnehmen. Den doppelte Einstellmöglichkeiten sorgen sicher nur für Fehler. 
Also ich wäre dafür, diese Einstellungen in der Benutzerkonfig bzw. den Site-Settings zu belassen und zwar aus zwei Gründen:
- Diese Einstellungen konfigurieren nicht das PM-Modul selbst, sondern dessen Nutzung.
- Je mehr Dateien (hier /admin/userconfig.php, /admin/settings.php, /modules/User_Registration/index.php, /modules/Your_Accont/config.php und /config.php) ausserhalb des eigentlichen PM-Moduls verändert werden, desto aufwendiger und schwieriger wird's für die Nutzer des Extention-Moduls, dies zu implementieren. Zusätzlich ist zu berücksichtigen, dass bei möglichen Updates die genannten Dateien immer wieder neu angepast werden müssten, was IMHO einen unnötigen Aufwand für uns und/oder die Nutzer bedeuten würde.
Das wäre wiederum ein Eingriff ein Modul ausserhalb des PM-Moduls (
/modules/User_Registration/language/hello-*.php). Desweiteren ist hier zu berücksichtigen, dass es mehrere Sprachdateien gibt, die alle zur Bearbeitung aufgegriffen werden müssten. Wenn überhaupt, dann wäre eine
seperate Extension der Benutzerkonfig der bessere Weg.

Noch ein kleiner Hinweis zur PM-Begrenzung den man vielleicht nicht übersehen sollte, man könnte für jede Benutzergruppe eine extra Begrenzung wählen. Ich weiß zwar nicht ob das wer braucht, aber man sollte das im Adminmenü berücksichtigen. 
Woher soll man denn im Vorfeld wissen, wieviele Gruppen es gibt? Es ist sicherlich möglich, beim Aufruf der Konfig die aktuell existierenden Gruppen aus der DB auszulesen und entsprechende Eingabemöglichkeiten zu generieren. Auch eine, bei jeder neuen Gruppe, vergrösserte config.php zu erzeugen ist nicht wirklich das Problem. Beim Anlegen einer neuen Gruppe muss der jeweilige Admin dann "nur" dran denken, im Anschluss die PM-Konfig aufzurufen und ein neues/zusätzliches Limit anzulegen. Hier könnte man natürlich einen Hinweis in die Gruppenkonfig einbauen, was allerdings wieder eine Änderung an "Fremddateien" (
/admin/groups.php und
/admin/language/lang-*.php) zur Folge hätte.
Für einige Funktionen die hier angeführt sind, müssen wir das PM-Modul noch ein wenig umcoden, da diese Funktionen noch nicht vorgesehen waren.
z.B. * PM-Limit Ja/Nein
Hier würde ich folgende Auswertung vorschlagen:
- Wenn der Wert = 0, dann kein Limit
- Wenn der Wert > 0, dann ist der Wert das Limit
Somit bräuchte man keine
zusätzliche Konfig-Einstellung dafür.

* Zählt die Begrenzung auch für Admins? JA/NEIN
Das sollte das kleinte Prob in der Umsetzung sein, oder?

Wäre zu entscheiden, ob's nur den GOD-Admin betrifft [if (radminsuper == 1)] oder alle Admins [if (MX_IS_ADMIN)].
* Wie viel PM-Nachrichten auf einer Seite (dazu müssten wir noch eine Umblätterfunktion einbauen)
Das ist wohl etwas aufwendiger, aber natürlich nicht unmöglich. Bin allerding der Ansicht, wenn ich mir die bisherigen Limits von mehreren 100 PM so ansehe, dass das auf jeden Fall umgesetzt werden sollte. Eine Vorlage zu einer seitenweise Auflistung ist ja im Modul Members_List zu finden.
... aber vielleicht interessiert Euch die Anregung, per Adminmenü PN`s, die beispielsweise älter als xx Tage sind, durch einen Superadmin löschen zu können.
Dazu sind ja die Limits da. Wenn die erreicht sind, muss der User halt selbst entscheiden, welche PMs er löscht, um weitere neue speichern zu können. Ne Löschung per Superadmin würde IMHO möglicherweise soger einen unzulässigen Eingriff in die Privatsphäre des betroffenen Users darstellen.
Noch eins zu den Limits im Allgemeinen:
Irgendwo sollte es ein (hard-coded)
globales maximales Limit geben (z.B. 500, 1000 ?). Weil irgendwann wird die Datenbank "gesprengt" und die Schreie "Meine DB funzt nicht mehr - was soll ich machen?" werden uns verstärkt "verfolgen".

Desweiteren würde ich die Limits für Ein- und Ausgang nicht separieren sondern nur deren Summe begrenzen. In wie weit sich das auf den bisherigen Code auswirken würde, müsste Gerhard mal prüfen.
