Anbei eine aktualisierte Version 02.00.01 des Login Moduls. Ich hab Sie mal hier daran gehängt, weil es ja zum Lieferumfang gehört.

Die Einstellung Optionale Formularattribute für Passwort wird nicht übergeben, weil der Wert von
$mod['attributes_username'] eingetragen ist.

Ich hab den Beitrag von http://forum.sefrengo.org/index.php?showtopic=534&st=0# losgelöst und einen neuen Thread daraus gemacht, da
a) In dem Sammelpool unter http://forum.sefrengo.org/index.php?showtopic=534&st=0 nur die Module rein gehören, die tatsächlich Bestandteil des mitgelieferten Repositorys der Sefrengo 1.4 beta2 sind.
b) In einem eigenen Thread besser über das Modul diskutiert werden kann, wie ja bereits geschehen.

tja, dann sollten wir aber gleich für alle Module die mit SF geliefert werden hier einen Thread anlegen und genau so wie mit normalen Modulen verfahren.

Nein. Es geht darum, das der Benutzer alle Module bekommt, die mit dem Sefrengo Repository bei einer Neuinstallation mitgeliefert werden. Und das ohne sich in 50 Threads die Module zusammnzusuchen zu müssen.

tja, mit deinem System muss er dann für alle Module im Pack prüfen ob es denn nicht seit dem erscheinen des Packs für irgedeines der darin enthaltenen Module ein Neueres im Modul Forum gibt.

Da poste ich doch lieber gleich meine Änderungen im selben Thread wie das Pack und hab alles an einer stelle - also genau so wie ich es zuvor gemacht habe.

Wenn alle Standardmodule in einem Thread gepostet werden, wird das echt lustig, besonders wenn es dann Anmerkungen zu den einzelnen Modulen gibt...

Zur Erklärung:
Das Standardmodulpaket enthällt alle Module, die bei einer Neuinstallation der beta2 im Repository vorhanden sind.

Hintergrund ist, das alle, die Ihre Präsenz updaten wollen, damit die gleiche Modul Ausgansbasis haben.

Ich werden ein solches Paket für jedes Release einer Sefrengo Version veröffetnlichen. Zwischenversionen mache ich nicht.

Wenn Du Zwischenpakete veröffentlichen willst, kannst Du das gerne in einem sepataten Thread tun. Einzelne Module aber bitte immer erst in einen eigenen Thread, damit wir die Übersicht behalten und Anmerkungen zu den Modulen gleich dort gemacht werden können. Das hat sich in der Vergangenheit bewährt.

Hi
Warum werden denn die Module bei einem Update eigentlich nicht einfach im Repository des Systems (idclient=0) geupdatet? Dann kann man in den Projekten einfach durch Klick auf das Update-Icon seine Module updaten -- oder auch nicht wenn man nicht will. Das würde einen solchen Sammelthread überflüssig machen.

Zusätzlich würde ich für jedes Modul einen eigenen Thread im Modulforum öffnen in dem es das Modul nochmal als cmsmod-Datei herunterzuladen gibt (falls man z.B. ausversehen mal ein Modul aus dem Repository seiner Installation gelöscht hat). In diesem Thread können Vorschläge gemacht, Bugreports gepostet und Lösungsvorschläge gemacht werden. Updates werden wie bei normalen Modulen gehandhabt.

Im übrigen würde sich damit auch das "Bugs Module, Plugins, Sonstiges"-Forum unnötig werden, denn solche Bugs gehören in die netsprechenden Threads zu den Erweiterungen.

Soweit meine Meinung
Gruß, Peter

Weil die Module im diclient=0 verändert werden können, also auch bearbeitet. Damit kann für die Datenintegrität nicht garantiert werden. Wenn jemand da manuell Änderungen gemacht hat und das von da aus dann in sagen wir mal 5 Projekte verteilt hat, wird der sich ziemlich freuen, wenn seine Änderungen auf einmal weg sind.

Hi

Wenn ein Modul im Repository (idclient=0) bearbeitet wird ändert sich der zweite Teil der Repo-ID (mod:dfbc83af929dc44d0bb85fdef4ef3010:4e5865ad). Es kann also erst ein DELETE auf die alte ID gemacht werden (der bei einer bearbeiteten Version ins leere Läuft) und anschließend ein INSERT mit der neuen ID.
Fals ich das Modul nicht bearbeitet habe wird also das alte Modul geupdatet, ansonsten wird das neue Modul als weiterer Eintrag eingefügt.

Gruß, Peter

@mazdermind: also das ist ja überhaupt nicht mehr nachvollziehbar, insbesondere bei großen Installationen. Da ist der manuelle Weg wesentlich nachvollziehbarer und sicherer.

@björn: ich sehe keinen vorteil deiner methode die module einzeln erst bei einer neuen Version zu posten. Besser ist es erst gar keinen Pack zu posten, sondern die Module welche bei einer Version mitgeliefert werden so wie früher als Updatepack direkt in das Installationsarchiv zu packen und für jedes Modul auch einen entsprechenden Thread im Downloadforum anzulegen.

Nuja aber wozu habe ich denn sonst diese Updatefunktion?Wo ich doch hin will ist ein One-Click-Update. Immoment ist das noch nicht so schlimm aber wenn ich mal in richtung Online-Repository weiterdenke...

Der zweite von dir angesprochene Punkt ist vorerst aber auch okay.

Gruß, Peter

die update funktion ist grundlegend ja schon ok. nur halte ich es nicht für sinnvoll, dass zentrale repository automatisiert zu aktualisieren - zumindest nicht solange es nicht eine ordentliche versionverwaltung gibt, ein rollback möglich ist, oder man module z.b. von einem update gänzlich ausschließen kann.

Es geht nicht um die einzelnen Module, sondern um das Paket.



Die Threads mit den einzelnen Modulen ergeben sich mit der Zeit automatisch. Das Pack dezentral vom Setup zu halten ist für mich die bessere Lösung
- weil schnell auf die Module zurückgegriffen werden kann. Bei vielen vorhandenen Installationen sind die Setupdateien ja nicht mehr da, wenn nach "Vorschrift" gelöscht.
- das Handling im CVS ist leichter. Durch die sich dauernd ändernden Dateinamen ist das mühsam.
- das Pack kann besser von dritten gepflegt werden (das aktuelle pack hat z.B. zum gröten Teil amk zusammengestellt und ich mußte nur noch drüberschauen und ein wenig korrigieren).

so habe ich es auch verstanden


aber dadurch muss man dann immer nachsehen wo habe ich gerade welches aktuell version habe. wenn alle standardmodule im downloadbereich wären hat man eine zentrale stelle mit dem aktuellen stand auf die man sich verlassen kann.


also nachdem ein upload der module nur vom lokalen pc möglich ist muss man die sowieso getrennt entpacken. egal mit einen externen pack oder aus dem installationsarchiv.


wer hat gesagt, dass dieses modulpack in das cvs sollen? ich habe vorgeschlagen sie in das installationsarchiv zu packen. so wie es früher auch war.


auch das ist mit meinem vorschlag möglich.

Beide Möglichkeiten haben sicher ihr Vor- und Nachteile. Ich hatte beide Möglichkeiten ausprobiert, wovon ich mit der jetzigen besser zurecht komme. Daher mache ich es so.

Disskussion beendet.

na wie du meinst ....

Mein ich. „Hier stehe ich, ich kann nicht anders, Gott helfe mir, Amen"

ich hätte mal eine frage zum loginmodul... ich sehe das sich ein paar sachen verbessert haben aber leider auch ein paar verschlechtert

ich benutze mod rewrite und nun kann ich nurnoch eine id eintragen die leider nicht mehr aufgelöst wird.... vorher hat man aus einem pulldown menu eine seite wählen können was ja nun nicht mehr da ist.... aber es hat funktioniert

mit den styles habe ich es noch nicht versucht meine seite anzupassen aber ich bin mir grad nicht sicher ob das machbar ist die formfelder mit eigenen styles zu belegen da an der stelle ein ganzer tag ausgespuckt wird auf den man keinen einfluss hat....

kann mir mal jemand sagen wie ich das ding zum laufen bekomme ohne auf das alte modul 1.4 downgraden zu müssen?

die neuen funktionen sind ja toll aber wenn es nicht geht mit meiner konfig ist es blöd bzw. sinnlos....

Naja z.B. in dem du das Modul an deine vorstellungen anpasst
Sefrengo ist halt noch nicht Stable und an den Modulen muss auch noch gearbeitet werden...

Gruß, Peter

oder ich eben es bei der alten version belasse
war nicht sehr konstruktiv

andere meldungen?

ich frag mich nur warum das modul hier unter den "fertigen" steht ... für mich gehört das in die abteilung beta.... man kann es nicht mal deaktivieren im backend.... und der rest den ich schon vorher mal angesprochen hatte....

also zuverlässiger funktioniert das loginmodul 1.4.1 meiner meinung nach... da fehlen eben die genannten zusätzlichen features aber es geht....

Äh, was? Welche ID? Bei welcher Aktion? Wie haben das Loginmodul bei aktiviertem mod_rewrite=2 im Einsatz und bei uns macht es keine Probleme.

hab auch mod_rewrite=2 und es geht nicht .... kommt eine weisse leere seite...

Mit ID meinte ich die ID in der Modulconfig. Mit Aktion meinte ich: Welche Configoption trifft das in der Modulconfig?

Poste doch bitte einfach mal ein Bild von Deiner Config (des Moduls). Weiße, leere Seite hört sich bei mir an offline geschaltete Seite, Kategorie an. Da scheint ja doch ein redirect ausgelöst zu werden. Das die Seite gar nicht existiert, ist eine andere Möglichkeit.

Hallo?

Hi
Ich nehme an er meint das Feld "Nach Login weiterleiten auf Seite" resp. "bei Logout". Anstatt einer ID-Eingabe sollte hier eine auswahlbox mit den vorhandenen Seiten stehen. Was es mit dem Auflösen auf sich hat.. ich kann nur raten:
Wird als ID z.B. 3 eingegeben, leitet das Modul anschließend (bei mir) auf index.php?lang=1&idcatside=3&view=preview&sefrengo=.... weiter. mariop3 erwartrte hier vllt. einen mod_rewrite-Pfad. Da wir uns aber im preview-Modus befinden ist es schon korrekt dass dort nur die index.php angesprochen wird. Wie sich das Modul bei Nur-Frontend-Logins (also ohne preview/edit-Mode) weiß ich leider nicht, hier sollte IMO auf einen mod_rewrite-Pfad umgeleitet werden.

Beim Ausloggen sieht man den Effekt sehr schön. Ich habe beim Ausloggei neine Weiterleitung auf ID 1 konfiguriert und werde auf die URL /index.php?lang=1&idcatside=1 gelenkt. Hier sollte vorher rewriteGetPageUrl aufgerufen und auf die rewrite-URL weitergeletet werden. Ich weise auch nochmal drauf hin dass die Ausgabe von rewriteGetPageUrl in die API-Klassen für Dateien und Ordner aufgenommenwerden sollte.


Gruß, Peter

also wenn das die dinge sind die mariop3 beanstandet, dann sind das maximal feature requests und keine bugs. wobei ich finde das es jedem zuzumuten ist eine id ohne auswahlselect in ein feld einzugeben. ansonsten läuft das modul sehr stabil und hat mit recht den status stable und nicht beta. wer die vorgängerversion nutzten will sei aber wirklich gewarnt, den die hatte wirklich bugs - und keine kleinen

Ja, das muss rein. Ebenso eine Funktion im Seitenobjekt, das zu einer Kategorie alle Seiten in beliebiger Sortierung ausgibt und im Kategorieobjekt selbiges halt nur mit den Ordnern. Dann hätten wir eigentlich alle Funktionen zusammen, um den $con_tree und $con_side Array zu beerdigen.

ja genau das meinte ich.... sehr schön beschrieben




aber das mit der id eingeben war nicht das problem... die seiten gab es.... aber er hat sie eben dann nicht mehr per mod-rewrite umgesetzt ....
das war etwas was in der alten version gut gelöst war..... bzw. funktioniert hat....

ich würde das neue modul gerne einsetzen wenn die einstiegsseite auch angezeigt wird

ok, dann sind das alles keine bugs sondern feature requests.

man geht das schnell hier

und was mache ich nun in dem fall?

warten das jemand das modul um deine wünsche erweitert, oder du machst es selbst. auf jeden fall würde ich dir raten nicht das alte login modul zu benutzen, weil das hat böse fehler. dagegen sind diese "unschönheiten" mit den nicht umgeschriebenen urls eine kleinigkeit.

Da hat sich ein kleiner Bug eingeschlichen. Er wurde bereits hier erwähnt.


Ist wahrscheinlich eh klar, aber der Vollständigkeit wegen hier der Nachtrag. Richtigerweise muss es natürlich so aussehen:

Noch eine Frage zum Login-Modul:

Können sich eigentlich gleichzeitig verschiedene Benutzer mit einem usernamen anmelden?
Das würde ja gehen, wenn zusätzlich zur Kombi user + pass noch beispielsweise die SessionID erfasst würde....
Klingt schon wieder sehr kompliziert, was...

Hintergrund:
Es soll auf einer Seite einen geschützten Bereich geben, in dem sich aber ca. 50-100 User anmelden können. Da es nur eine Authentifizierung sein soll, die einzelnen User aber weder etwas Posten noch sonstige persönliche Infos benötigen,wollte ich nicht 100 Benutzer einrichten. Nun die Frage: Geht dies mit einen einzigen User in SF?

Nebenbei: Wie viele User können eingerichtet werden? Wo wäre eine sinnvolle Grenze, die nicht überschritten werden sollte?


Gruß
Jan

ich gehe mal aus das dies funktioniert ... schliesslich hab ich's jetzt so bei meinem aktuellen projekt bzgl. download-bereich eingebaut ... du kannst die seite ja mal in 3 unterschiedlichen browsern gleichzeitig aufmachen und es ganz einfach testen

scheint tatsächlich zu gehen


Doch ein Bug?
Also bei mir funktionieren die Weiterleitungen nicht so ganz, also die Weiterleiten nach login und nach logout.
Die "dritte" bei erneutem Aufruf login schon. Hat das wer von euch am Laufen?

"Unschön" ist auch folgendes:
Wenn das Login-Modul auf allen Seiten z.B. in der Kopfzeile präsent ist, führt das Ausloggen, sofern man sich auf einer geschützten Seite befindet, unweigerlich zu einer weißen Seite. Ist zwar klar warum, schön ist das aber nicht.
Gibt's dafür eine besser Lösung?

Viele grüße
Jan

Hallo,
ich weiss nicht, ob das mit den beschriebenen Problemen zu tun hat, ich habe in der Frontendausgabe des Moduls folgende Zeile gefunden, die da bestimmt nicht hingehört:



Müsste in den Zeilen 20ff zu finden sein.
Gruss, Andreas

oh das passt schon, das ist nur für die lokale entwicklung da. und $is_dev steht ja auf false.

ok, woran liegt es dann, dass die Weiterleitung nicht so läuft, wie zu erwarten wäre?

kann ich dir nicht sagen, bei mir funktioniert das ....

In Zeile 222 werden die {form_attributes} ersetzt:


Das Hinzufügen von name="login" führt dabei leider dazu, dass der Output nicht mehr xhtml1.0 strict konform ist.
Daher die Frage: Braucht man name hier zwindend für irgendetwas oder könnte man das einfach weglassen?

Ich denke, Du kannst das weglassen.

Hallo Leute , ich bin noch ziemlich neu mit diesem CMS unterwegs. Und schon schleichen sich die kleinen Probleme ein , ich hoffe es ist nur etwas banales oder ein denkfehler von mir
Also zum Problem:

Ich habe einen geschützten Bereich den ich nur bestimmten Usern zugängig machen möchte. Diese sollen sich aber alle mit den gleichen Zugangsdaten einloggen können. Ich mache also einen neuen Benutzer und eine neue Gruppe . Dieser neue Benutzer kann sich nun leider nicht einloggen. Mache ich nur einen neuen Benutzer ohne Gruppe kann ich mich auch nicht einloggen.
Nehme ich aber die logindaten von dem admin geht alles wunderbar .
Kann mir da jemand weiter helfen ?