Typo3 Xing API Data Import Extension

Alumnivereine, die ein eigens Portal haben, werden es kennen. Fast kein User macht sich die Mühe ein vollständiges Profil aktuell zu halten. Wir haben das Problem jetzt damit gelöst, dass die User ihre Daten von Xing mit wenigen Klicks importieren können. Das Ganze ist als freie TYPO3 Extension verfügbar und zwar hier:
http://typo3.org/extensions/repository/view/dix_xingsync

Nachdem wir die Extension jetzt ca. 4 Wochen laufen haben, ist das Feedback äußerst positiv und die Zahl der Vollständigen Profile bei knapp 15 % von 600 Mitgliedern angekommen. Noch ein weiter weg bis zur Perfektion, die Seite sieht nach dem Login alleine durch die Mitgliederfotos aber wesentlich ansprechender aus als ständig auf die Dummy-Fotos zu schauen.

Nächste Schritte sind, das Thema immer wieder in Mailings anzusprechen (bei den Personen, die noch nicht vollständig sind,einfach in dem man noch einen Absatz mehr einfügt, wenn man gerade eh ein Mailing macht). Für neue Mitglieder ist der nächste Schritt eine Routine,die nach 2 und 4 Wochen dazu auffordert das Profil bitte zu aktualisieren.

Serienemails mit Outlook 2010 und Standardkonto

Nachdem es mich unnötig Zeit gekostet hat, hier ein kurzer technischer Hinweis, wie man mit Outlook 2010 und Word 2010 Serienemails versendet, wenn man mehrere Konto hat.

Bei mir wurde immer das falsche Emailkonto als Absender verwendet - obwohl ich das gewünschte Konto vorher entsprechend als Standardkonto festgelegt hatte. Die Lösung des Problems war am Ende das Einfügen eines neuen Registry-Schlüssels, wie es hier steht:

http://www.wintotal.de/tipparchiv/?id=1933

Das 2. Problem war die Signatur, die nicht mehr verwendet wurde. In 2007 ging das noch, ab Outlook 2010 verwendet Word bei Serienmails diese nicht mehr, man muss sie also direkt in den Serienbrief aufnehmen. 

Felder doppelt im Backend - Werte unsichtbar

Ein simples Problem hat mich gestern wieder unnötig lang beschäftigt: Im Backend wurde beim editierender FE_USER Einträge das Feld für den Nachnamen zwar angezeigt,aber es war leer. Ein Blick in den Quellcode und die Datenbank zeigten schnell, dass der Wert durchaus da ist. Im Quellcode in einem unsichtbaren Feld, aber eben nicht im sichtbaren Input Field.

Am Ende war die Lösung simpel: Ich hatte das Feld doppelt im Backend, aber auf unterschiedlichen Tabs, so dass es mir nicht aufgefallen war. Zu lösen ist das dann, indem man im TCA-Array sucht, welche Werte beim Key

$TCA['fe_users']['types']['0']['showitem'] 

vorhanden sind. Bei mir stand dort zwei Mal das Feld last_name drin. Eins entfernt und schon ging's wieder...

UPDATE: Besser spät als nie eine Richtigstellung. Die Ursache war korrekt, aber die Lösung schrecklich falsch. Ich hatte in einer Extension in der ext_tables.php das Feld last_name in addToAllTCAtypes hinzugefügt, obwohl das Feld in der Extension gar nicht selbst erstellt wurde. Dort hab ich den Wert gelöscht und schon funktionierte alles wunderbar.

Ansprechende Texte schreiben

"Toller Event, aber wieder hat keiner den Artikel gelesen." Dieser Gedanke beschleicht nicht nur mich in der Alumni Arbeit ab und an. In der Alumniarbeit tummeln sich sicher nicht nur ausgebildete Medienexperten, sondern auch viele Quereinsteiger. Einladungen und Berichte sollen natürlich trotzdem spannend sein und von den Mitgliedern gelesen werden. Durch Zufall ist mir neulich von Wolf Schneider das Buch "Deutsch für junge Profis: Wie man gut und lebendig schreibt" in die Hände gefallen. Abgesehen davon, dass es kurzweilig zu lesen ist, waren auch genug Tipps drin, die in der Alumniarbeit Anwendung finden sollten. Die besten Tipps aus meiner Sicht sind:

• Der erste Satz muss spannend sein und Lust auf mehr machen
• In 350 Zeichen Alles sagen
• Nebensätze reduzieren und nur nach dem Hauptsatz 
• Jeder 3. Satz endet mit Nebensatz zum Auflockern
• Texte als Qualitätskontrolle laut lesen – muss sich gut anhören
• Für Werbung/Flyer: In 2 Sekunden den Sinn erfassen können

Die Umsetzung in die Praxis ist nach eigener Erfahrung mühsam. Es hilft aber, sich solche und ähnliche Regeln zu merken bzw. beim Verfassen des nächsten Newsletters mal vor Augen zu führen und die eigenen Texte dagegen zu halten.

Fe_Login erweitern: Username und Emailadresse zum Login verwenden

Wer kennt das nicht: Man hat eine Typo3 Seite mit Community und regelmäßig kommen Fragen per Email, weil der Username vergessen wurde? Wie schön wäre es da, wenn als Username auch die Emailadresse gehen würde. Für die Standardloginvariante fe_login wurde mein Featurerequest (http://forge.typo3.org/issues/24708) leider abgelehnt, allerdings mit dem Hinweis, wie man diese Funktionalität in einer eigenen Extension bereitstellt.

Für an diesem Feature interessiert sind, hier die Anleitung, wie man das hinbekommt.

Wichtig: Wenn man dieses Feature nutzen möchte, muss die Emailadresse einmalig (unique sein). Das kann entweder hart über die Erstellung eines Unique Index auf die fe_user Tabelle erfolgen, oder indem man im Backend und Frontend die die Werte bei Eingabe überprüft. 
Hier gibt es auch wieder 2 Varianten: Entweder sind die Emailadresse global einmalig oder nur lokal einmalig. Global bedeutet fe_users weit, lokal bedeutet, dass sie nur einmalig innerhalb einer Seite im Backend sind. Letzeres bedeutet, dass in der fe_users die Felder „pid“, „email“ und „deleted“ ZUSAMMEN  unique sein müssen.  

Ich beschreibe hier eine Variante mit Überprüfung bei Eingabe und lokaler Einmaligkeit.

Als erstes muss überprüft werden, ob es aktuell Emailadressen gibt, die doppelt vorkommen. Dabei hilft folgendes SQL:

 Select pid, email,count(1) as mycnt from fe_users where deleted = 0 group by pid,email having mycnt > 1Select pid, email,count(1) as mycnt from fe_users where deleted = 0 group by pid,email having mycnt > 1  

Diese Fälle müssen gelöst werden, bevor man die Loginvariante freischaltet.

Als nächstes brauchen wir für’s Backend die Möglichkeit sicherzustellen, dass die Emailadresse einmalig ist. Dazu müssen wir eine neue Extension erstellen oder in einer bestehenden Extension eine neue Evaluationsklasse hinzufügen. Letzteres geht in drei Schritten:
1. ext_tables.php erweitern, so dass das fe_users Feld „email“ evaluiert wird:

 $TCA['fe_users']['columns']['email']['config']['eval'] = 'trim, lower, tx_felogin_emaillogin_uniqueemail, required';  

Trim, lower und required sind bereits existente Evaluationsmethoden “felogin_emaillogin_uniqueemail”.

2. Die Methode felogin_emaillogin_uniqueemail “anmelden” in ext_localconf.php

 $TYPO3_CONF_VARS['SC_OPTIONS']['tce']['formevals']['tx_felogin_emaillogin_uniqueemail'] = 'EXT:felogin_emaillogin/Resources/Private/Classes/class.felogin_emaillogin_uniqueemaileval.php';  

3. Das php Script an den eben definierten Ort kopieren (alle Files weiter unten im  .t3x file zum Runterladen)

An dieser Stelle kann man schon mal testen, ob man im Backend 2 Nutzern die gleiche Emailadresse geben kann.

Jetzt kommt das Frontend dran. Auch hier muss in der ext_localconf.php eine Anpassung erfolgen. Es wird ein neuer Authorisierungsservice hinzugefügt:

 t3lib_extMgm::addService(  
      'felogin_emaillogin',  
      'auth',  
      'tx_felogin_emaillogin_authservice',  
      array(  
           'title' => 'FE-Authentification via eMail',  
           'description' => 'looks up given username in email field (to allow using both email and username) ',  
           'subtype' => 'getUserFE',  
           'available' => TRUE,  
           'priority' => 70, // must be higher than tx_sv_auth (50) and rsaauth (60) but lower than OpenID (75) if you want to use OpenID too  
           'quality' => 70,  
           'os' => '',  
           'exec' => '',  
           'classFile' => 'EXT:felogin_emaillogin/Resources/Private/Classes/class.felogin_emaillogin_authservice.php',  
           'className' => 'tx_felogin_emaillogin_authservice',  
      )  
 );  

Im nächsten Schritt muss die Klasse an den entsprechenden Ort kopiert werden (auch wieder im .t3x File)

Jetzt klappt das Login schon mit der Emailadresse. Allerdings sollte noch die Registrierung so angepasst werden, dass auch hier jede Emailadresse nur einmal vergeben werden kann. Dazu nutze ich die Erweiterung sr_feuser_register. Hier kann man mittels Typoscript die Anpassungen vornehmen:

 plugin.tx_srfeuserregister_pi1.edit.evalValues.email = email,uniqueLocal  
 plugin.tx_srfeuserregister_pi1.create.evalValues.email = email,uniqueLocal  

Jetzt fehlt noch das Loginformular selbst. Dort habe ich Quick and Dirty einfach die deutsche Übersetzung wie folgt angepasst.

 plugin.tx_felogin_pi1._LOCAL_LANG.de.username=Userame/Email

Alle Dateien findet ihr in folgender Extension zum herunterladen, für die ich keine Garantie übernehme, die aber funktioniert :-)

Form: Einfaches Nachrichtensystem für Mitglieder mit Spamschutz

Das Problem: Es gibt eine Community und Personen sollen sich untereinander erreichen können, trotzdem sollen Emailadressen nicht im System angezeigt werden. Außerdem wollte ich kein weiteres großes Plugin und die Nachricht sollte direkt an die Emailadresse des anderen Nutzers gehen und den anderen Nutzer nicht dazu zwingen sich erst einloggen zu müssen.

Die Lösung: Eine Erweiterung der Form-Extension um 2 Postprocessoren: Der eine schickt Emails im Namen des eingeloggten Users an einen anderen User und sendet gleichzeitig eine Bestätigungsnachricht an den Sender (ohne aber die Emailadresse des Originalempfängers preis zu geben). Der 2. Postprocessor verhindert, dass ein User mehr als 1 Nachricht alle 60 Sekunden verschickt und baut gleich noch eine Statistik auf.

Im Typoscript sieht das Formular so aus: 

 prefix = tx_form  
 confirmation = 0  
 postProcessor {  
     1 = minimumdelaychecker  
     1 {  
        delay=60  
        errorPageID = 226  
     }  
      2 = memberMail  
      2 {  
           recipientEmailField = EmpfaengerID  
           senderEmail = sender@domain
           senderName = Absendername 
           subject = Direktnachricht von Domain Mitglied:   
           replyToField = absenderemail  
         messages {  
                success = Deine Nachricht wurde erfolgreich an das Mitglied gesendet. Du erhälst von der Email eine Kopie  
           }  
      }  
 }  
 10 = FIELDSET  
 10 {  
      legend {  
           value = Private Nachricht an ein anderes Mitglied senden  
      }  
      20 = TEXTLINE  
      20 {  
           name = absenderemail  
           readonly = readonly  
           value = {TSFE:fe_user|user|email}  
           label.value = Deine Emailadresse  
      }  
      30 = TEXTLINE  
      30 {  
           name = name  
           readonly = readonly  
           value = {TSFE:fe_user|user|first_name} {TSFE:fe_user|user|last_name}  
           label.value = Dein Name  
      }  
 32 = TEXTLINE  
 32 {  
   name = Empfänger  
 readonly=readonly  
 value = {gp:receiverName}  
 label.value = Empfänger  
 }  
      40 = TEXTAREA  
      40 {  
           cols = 50  
           rows = 10  
           name = Nachricht  
           label.value = Nachricht  
      }  
 41 = HIDDEN  
 41 {  
   name = EmpfaengerID  
  value = {gp:receiverID}  
 }  
      50 = SUBMIT  
      50 {  
           name = Submit  
           value = Abschicken  
      }  
 }  

Das Formular selbst ist sehr einfach gehalten. Wie man Variablen im Formular auswertet, habe ich in diesem Blogbeitrag erklärt.

Der "Minimumdelaychecker" ist ein Postprocessor, der eine kleine Statistik erstellt, wer wie viele Nachrichten verschickt hat und wann die letzte Nachricht geschickt wurde. Dazu werden in der fe_users-Tabelle die 2 Felder user_system_number_of_messages und user_system_last_message_timestamp erwartet. Diese Felder können natürlich auch umbenannt werden, dann muss aber auch der Postprocessor angepasst werden. Diesen Postprocessor gibt es hier zum runterladen. Wenn jemand innerhalb der im Typoscript definierten Zeit (Variable "delay") 2 Nachrichten schickt, wird er auf die Seite mit der in der ebenfalls in Typoscript (errorPageID) definierten Seite umgeleitet.

Der 2. Postprocessor ersetzt den Standard Mail Postprocessor. Runterladen könnt ihr ihn hier. Dieser Postprocessor setzt zum einen als Absender nicht die Emailadresse, die vorher im Formular angezeigt wurde, sondern diejenige, die für den eingeloggten User hinterlegt ist. So wird verhindert, dass jemand  die Daten im Form vor dem senden editiert. Das geht in HTML auch dann, wenn der die Felder - wie im Beispiel - gesperrt sind.

Was noch fehlt? Der Aufruf der des Formulars. Hier habe ich es mir einfach gemacht:. Aus einer anderen Extension heraus rufe ich die Seite, die das Formular enthält auf und übergebe per URL die ID (und den Namen des Empfängers):
?receiverID=272&receiverName=Dein%20Name

Ich hoffe, die Beschreibung ist ausführlich genug. Wenn nicht, fragt ruhig :)