mod_form 4.1

[MarkusR]

Ist mir auch vor einigen Tagen aufgefallen.

Das tritt natürlich nur dann auf, wenn die Formularrubrik eine geschlossene Rubrik ist oder man einen Login innerhalb der Formularrubrik versucht.

Eigentlich muß man nur member.php durch die member.php des _rubric-Verzeichnisses ersetzen... geht bestimmt schneller als ein "Rückbau"

[Mr. Magpie]

Eigentlich muß man nur member.php durch die member.php des _rubric-Verzeichnisses ersetzen... geht bestimmt schneller als ein "Rückbau"

Hab' ich mir auch gedacht, dann aber beim Dateivergleich etwa 30 Unterschiede und insgesamt etwa 5,3 KByte Größenunterschied festgestellt... da hatte ich dann keine Lust die Relevanz der Unterschiede im einzelnen zu eruieren.
So war der Rückbau hier schneller

[MarkusR]

Und vielleicht interessiert sich ja jemand dafür, wie man ein Login für Mitglieder realisiert, die dann nur ein Passwort aber keinen Usernamen benötigen, weil dieser eben vorbelegt ist. Eben mit dem ersetzten Code, wobei der "username" natürlich angepasst werden kann...

[Mr. Magpie]

Hallo Markus,
hast du schon einmal daran gedacht, die Möglichkeit eines Double-Opt-In einzubauen? Ich hätte da nämlich gerade eine Anwendung ("Stellenbörse") hierfür:

Der Inserent soll seine Angaben im Formular machen,
diese werden als eMail an den Website-Betreiber gesandt und parallel an den Inserenten,
das Inserat (der Formularinhalt) wird in Artikelform erst nach Anklicken eines Bestätigungslinks durch den Inserenten frei gegeben.

Wäre das nicht eine schöne "Fingerübung" für dich?
Ich mach' auch den Tester

[MarkusR]

Das wäre nicht so wahnsinnig schwierig.

Ich weiß nur nicht, ob statt der Freigabe durch einen Redakteur ein Double-Opt-In Missbrauch wirklich vermeidet.

Außerdem müsste dafür ein Platzhalter her, um den Link nicht zwingend erst am Ende des Mails auszugeben...

Ist also mit etwas Arbeit verbunden, aber sicher machbar.

[Mr. Magpie]

Das wäre nicht so wahnsinnig schwierig.

Ich weiß nur nicht, ob statt der Freigabe durch einen Redakteur ein Double-Opt-In Missbrauch wirklich vermeidet.

Nicht völlig, aber zumindest könnte man als Betreiber der Seite ein bisschen besser die Echtheit der eMail-Adresse verifizieren, um Fremdeintragungen einzudämmen.

Mir persönlich ist es immer ein wenig peinlich, wenn ich den Kunden beibringen muss, dass das ConPresso nicht kann.

[MarkusR]

Als allererstes muß der Kunde ja verstehen, daß er ein Content Management System hat, also keine Shopsoftware, keine Auktionshaus, kein Forum etc.
Warum sollte also so etwas möglich sein...

Anyway, hier ist die Fingerübung:
im Archiv stecken die Dateien
confirm.php
includes/parser_c_form.inc.php und
includes/parser_r_form.inc.php

Verwendet man im Mail-Template den Platzhalter <!-- Form: confirmation; --> dann wird an dieser Stelle eine URL in der Form
http://meindomain.de/cpoDir/mod_form/co ... h48dh39hr9
eingesetzt, wobei nr die Artikelnummer ist und hash ein md5-Schlüssel aus Titel und Publikationsdatum
Durch Anklicken des Links wird der Artikel freigeschaltet (egal ob er das schon war oder nicht)
Dabei kann in der Meldung der Inhalt des Formulares nochmal ausgegeben werden.

Die Texte sind derzeit noch in confirm.php von Hand eincodiert, können aber später noch zu den Moduleinstellungen kommen, wenn soweit alles funktioniert.
Dabei wäre es dann sinnvoll das ganze gleich auf folgende Möglichkeiten zu verändern: sperren (oder verfallen), löschen.
Kompliziert wird es, wenn noch "editieren" dazu kommen soll...

[Mr. Magpie]

Vielen Dank,

das wird auf jeden Fall noch in der kommenden Woche getestet.

Der Kunde, ein Verband, weiß schon, dass er nur ein CMS hat. Im konkreten Fall geht es um eine Art Stellenbörse. "Inserenten" sollen ihr Profil in ein Formular eintragen. Die Daten werden nicht auf der Website veröffentlicht, aber der Verband leitet die "Inserate" in Form von PDFs an (ausgewählte) Mitglieder weiter. Da ist es sicher verständlich, dass diese etwas sensiblen Daten einer gewissen Verifikation - zumindest des Inserenten - bedürfen.

Ist doch auch ein schöner Mehrwert für dein Modul.

[MarkusR]

Dann gibt's zum Testen noch eine bessere Version... bald.

Ich habe jetzt implementiert:
freigeben, löschen, blocken, verfallen

je nachdem was man im Mail anbietet stehen dem User die entsprechenden Optionen zur Verfügung. Bei Bedarf alle. Wobei ein Link keinen Rückschluss auf den Aufbau eines anderen gibt.
Es kann also keiner, der nur einen Löschen-Link erhält erraten oder errechnen wie der Freigeben-Link aussieht, da die Aktion mit verschlüsselt wird.

Und jetzt kommt eine Option dazu, die schon für zwei Projekte gepasst hätte, bisher aber auch mit Gehirnschmalz erledigt werden konnte: Eine Verfallszeit (Dauer), sowas wie ein MHD . Man kann also im Modul einstellen, wie lange der Eintrag online bleibt...

[Mr. Magpie]

...eine Option dazu, die schon für zwei Projekte gepasst hätte, bisher aber auch mit Gehirnschmalz erledigt werden konnte: Eine Verfallszeit (Dauer)...

Das wäre wahrscheinlich mein nächster Wunsch geworden! Es mangelt beim Kunden oft nicht an Gehirnschmalz, sondern an Überblick, Voraussicht und Organisationstalent. Da ist alles hilfreich, was (teil-)automatisiert werden kann.

[MarkusR]

Ich habe eine 4.1b zum Testen auf meine Downloadseite gestellt.

Neben dem oben beschriebenen gibt es weitere Neuerungen wie Einbindung von z.B. Google-Conversion-Codes, freie Definition der Absendeschaltflächen, automatische Umbenennung von Dateiuploads, um Uploads erst verifizieren zu können / Missbrauch zu vermeiden. Außerdem lassen sich die Dateitypen einschränken.

Für ein Update müssen nach dem Überschreiben der Dateien im Einstellungsmenü die fehlenden Einträge vorgenommen werden.

Im Template können die Bestätigungen so eingebaut werden:

Code: Alles auswählen

<!-- ifSet: mod_form_confirmation; -->
Eintrag verifizieren
<!-- FORM: confirm; --> 
Eintrag löschen
<!-- FORM: delete; --> 
Eintrag sperren
<!-- FORM: block; --> 
Eintrag archivieren
<!-- FORM: expire; --> 
<!-- /ifSet -->