[HowTo] Front-End-User-Plugins

Gesperrt
OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

[HowTo] Front-End-User-Plugins

Beitrag von OliverL » So 22. Jun 2008, 20:28

Beitrag in http://www.contenido-wiki.org übertragen!

Bei "schlechter" Bewertung wäre ein Kommentar nett was ich verbessern könnte. THX


Ich kann jedem nur empfehlen seine eigene Arbeit zu Dokumentieren den mir ist ein keiner aber unschöner Fehler aufgefallen.

Das HowTo wurde aus meinen Erfahrungen mit 4.6.23 erstellt. Sollte aber auch mit 4.6.15 -> 4.8.x funktionieren da es hier keine Änderungen gab.
Das Ziel von Front-End-User-Plugins ist es die FEU-Daten update fähig zu ergänzen.
Hier für müssen die entsprechenden Plugins lediglich in das entsprechende FEU-Verzeichnis im Pluginordner abgelegt werden.

Verzeichnis-Pfad: htdocs/contenido/plugins/frontendusers/

Wichtig: Jedes Plugin reduziert die Geschwindigkeit des Backend. Aus diesem Grund werden nur alle 60 sec. nach neuen Plugins gescannt. Ein Plugin ist so Strukturiert das mehrere Wert/Eingaben über ein und dasselbe Plugin verarbeitet werden können. So muss man für eine vollständige Postanschrift nicht je ein Plugin für Name, Straße, PLZ und Ort anlegen sondern nur eins.

Initialisierung:
Initialisiert werden die Plugins durch die folgenden Codezeilen der "config.plugin.php" im Unterverzeichnis "includes/".

Code: Alles auswählen

<?php
  // Pfad: htdocs/contenido/plugins/frontendusers/includes/config.plugin.php
  cInclude("includes", "functions.general.php");
  scanPlugins("frontendusers");
?>
In alten Versionen ist der Inhalt der Datei gleich mit der Funktionen "scanPlugins()".

FEU-Plugins
Als erstes sollte ein prägnanten und kurzen PluginName definiert werden. Hier bei sollte beachtet werden das dieser Name in Verzeichnis-, Datei- und Funktions-Namen verwendet wird. Es wird nicht direkt im Backend angezeigt.

Strukturübersicht:
Damit Contenido alle benötigten Dateien Findet ist eine gewisse Grundstruktur nötig.

Code: Alles auswählen

- myplugin/
  - locale/
    - de_DE/
      - LC_MESSAGES/
        - frontendusers_myplugin.po
    - en_EN/
      - LC_MESSAGES/
        - frontendusers_myplugin.po
  - myplugin.php
Das Basis-Verzeichnis muss den Namen des Plugin haben. Genau so muss die Plugin-PHP-Datei den Namen + ".php" haben und alle ".po"-Datein (Übersetzungsdatei). die entsprechende Sprache wir durch das Subverzeichnis definiert z.B. "de_DE" für Deutschland.

Auf das Übersetzen von PO-Datein werde ich hier nicht eingehen. Nur das in Plugins mit der Funktion i18n( $string, $domain ) übersetz wird.
$string ist der zu übersetzende Text und $domain der Pfad der Übersetzungsdatei bestehend aus PluginTyp + "_" + PluginName.
Beispiel: echo i18n( "Hallo Word!", "frontendusers_myplugin" );
Am Ende ein Beispiel einer PO-Datei.

Funktionsübersicht:
Jede Funktion beginnt mit "frontendusers_" + PluginName + Funktionsname.

Code: Alles auswählen

  1. _getTitle()
      gibt den Titel des Plugin zurück
   2. _wantedVariables()
      gibt die verwendeten VariablenNamen zurück
   3. _store()
      speicher die Daten
   4. _getvalue()
      gibt den passenden Wert zu einem bestimmten VariablenNamen zurück
   5. _canonicalVariables()
      Gibt die Titel/realen Namen einer Variable zurück
   6. _display()
      Ausgabe der Eingabmaske für das Backend
Funktion: frontendusers_myplugin_getTitle()
Mit dieser Funktion wird lediglich der Name des Plugin zurück gegeben und wird in der linken Spalte der Userdetails angezeigt. So kann man und sollte man auch einen allgemein gültigen (englischen) Namen über die PO-Datei übersetzen.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_getTitle() {
    return i18n("MyPluginTitle", "frontendusers_myplugin");   
}


Funktion: frontendusers_myplugin_wantedVariables()
Dies ist eine der wichtigsten Funktionen überhaupt. Sie definiert die Variablennamen die verwendet werden. Ein absolut eindeutiger Name ist die Grundvoraussetzung für das Funktionieren. Das kann man mit dem folgenden Schema sicherstellen:

"feup_" + PluginName + "_" + Variablenname

Damit, wie schon angesprochen, mehrere Werte gespeichert werden können müssen auch mehrere Variablennamen definiert werden können. Diese Namen werden durch die Funktion als Array zurück gegeben.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_wantedVariables() {
    // gibt die Variablen var1, var2 & var3 im Schema als Array zurück
    return array( 'feup_myplugin_var1', 'feup_myplugin_var2', 'feup_myplugin_var3' );
}
Funktion: frontendusers_myplugin_store( $aValues )
Mit store() werden die Daten gespeichert. Damit alle Daten gleichzeitig an die Funktion übertragen werden können werden diese als Array Übergeben. Hier bei ist der Array-Key gleich dem Variablenname und der Array-Wert die BE-Eingabe.

Für das einfache Speichern kann man das Objekt $feuser in der Funktion globalisieren und dann nutzen.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_store( $aValues )
{
  global $feuser;
 
  foreach( $aValues as $sValName => $sValString ) {
    $feuser->setProperty( "frontendusers", $sValName, $sValString );
  }
}
Funktion: frontendusers_myplugin_getvalue( $sName )
So simpel das Speichern der Daten ist, so simpel ist das holen. Als Parameter wird hier in $sName der in _wantedVariables() definiere Varaiblenname übergeben. In dieser Funktion wird diesmal kein Array übergeben sondern nur ein Name.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_getvalue( $sName )
{
  global $feuser;
 
  return $feuser->getProperty( "frontendusers", $sName );
}

Funktion: frontendusers_myplugin_canonicalVariables( $sName )
Damit die Usability im Backend gewährleistet werden kann, können den Variablennamen ein sprachspezifischer Titel zuweisen. Das hat den Vorteil das bei den Anzeigeoptionen im Backend im Feld "Suche in" ein Aussagekräftiger Titel steht und nicht unser Variablenname.

Zurück gegeben wird von der Funktion ein Array in den der Array-Key der Variablenname und als Wert der Titel. Der Titel sollte mit der i18n()_Funktion übersetzt werden.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_canonicalVariables()
{
    $return = array();
    $aVariables = frontendusers_myplugin_wantedVariables();
   
    foreach( $aVariables as $sName ) {
       $return[ $sName ] = i18n( $sName, "frontendusers_myplugin" );
    }
   
    return $return;
}
Funktion: frontendusers_myplugin_display()
So wie im Modul-Input kann man die Eingabemaske ausgestalten. Hier ein einfaches Beispiel um die Maske als Tabelle auszugeben mit den von diesem Plugin bereitgestellten Funktionen.

Beispiel:

Code: Alles auswählen

function frontendusers_myplugin_display()
{
    cInclude("classes", "class.htmlelements.php");
    $return = '<table width="100%" border="0" cellspacing="0" cellpadding="0">';

    $aWantVar = frontendusers_myplugin_wantedVariables();
    $aTitle = frontendusers_myplugin_canonicalVariables();

    foreach( $aWantVar as $sVar ) {
      
       $return.= '<tr>';
       $return.= '<td class="text_medium">'.htmlentities( $aTitle[$sVar] ).'</td>';
      
       $oInput = new cHTMLTextbox( $sVar, frontendusers_myplugin_getvalue( $sVar) , 128);
       $oInput->setStyle( "width: 100px;" );
       $oInput->setClass( "text_medium" );
      
       $return.= '<td class="text_medium">'.( $oInput->render() ).'</td>';
      
       $return.= '</tr>';
    }
    $return.= '</table>';
   
    return $return;
}

TIPP: Eventuell ist es einigen aufgefallen das es keine delete-Funktion gib. Das ist auch nicht nötig wenn man das Objekt $feuser nutzt, werden die Werte mit dem Löschen des FEUsers mit gelöscht. Für größere Datenmengen (eventuell eine Ein-/Anbinung eines Forum) sollten die CRC-Funktion "Contenido.Permissions.FrontendUser.AfterDeletion" verwendet werden.
Die Variable $idfrontenduser wird als einigster Parameter übergeben.

Beispiel PO-File

Code: Alles auswählen

msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2008-06-12 00:00+0100\n"
"PO-Revision-Date: 2008-06-12 00:00+0100\n"
"Last-Translator: = Oliver Lohkemper <lohkemper@team4media.net>\n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"

msgid "MyPluginTitle"
msgstr "Titel"

msgid "feup_myplugin_var1"
msgstr "Value 1"

msgid "feup_myplugin_var2"
msgstr "Value 2"

msgid "feup_myplugin_var3"
msgstr "Value 3"
Downloads:
plugins.zip


Bewertet diesen Beitrag
5 Punkte - 77% [ 7 ]
4 Punkte - 11% [ 1 ]
3 Punkte - 00% [ 0 ]
2 Punkte - 00% [ 0 ]
1 Punkte - 11% [ 1 ]
Stimmen insgesamt : 9
Zuletzt geändert von OliverL am Di 30. Sep 2008, 13:24, insgesamt 3-mal geändert.

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Beitrag von rethus » Do 26. Jun 2008, 20:02

5 Points von mir für deine Mühe.
Aber ehrlich gesagt, hab ich immer noch kein Plan, was das Plugin überhaupt bewirken soll:
Das Ziel von Front-End-User-Plugins ist es die FEU-Daten update fähig zu ergänzen.
Kannst du dass etwas ausformulieren? Die Leute, die sich nicht mit der Entwicklung deines Plugins beschäftigt haben, können nur schwer nachvollziehen, was das bedeuten soll.

Ich suche derzeit noch nach einer Erweiterung, die es FEU ermöglicht so ne Art eigene Profilseite anzulegen, und zu pflegen. Ist das sowas?
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

Beitrag von OliverL » Do 26. Jun 2008, 21:59

Das Ziel von Front-End-User-Plugins ist es die FEU-Daten update fähig zu ergänzen.

Das Bedeutet egal was mit den Kern von Contenido passiert das Plugin funktioniert (zu 99%) weiterhin.

Indirekt hilft es bei der erstellung einer Profilseite (wie hier im Forum unter Profil). Es schaft die Basis für die Daten. Die Plugins werden im Backend eingebunden und mit ihnen kann man Daten ergänzen. Somit kann man z.B. ein Plugin entwickeln für: Postanschrift, Messager, Userimage, Logsystem, ... .
-> Eingabemasken jeder Art

Bild
#1 - Standardfelder von Contenido
#2 - Mein Standard-Plugin für die meisten Fälle
#3 - Plugin aus den HowTo

Im HowTo werden die Funktionen und Struktur dargestält und mit Beispielcode ergänzt. Dennoch werden Plugins programmiert und setzt Kenntnisse in PHP voraus.

Frontend/Website
Möchte man Registrierte User haben so sollte man die folgenden Module haben:
- FEU-Registrieren
- FEU-Editieren
- FEU-Anzeige/-Liste

Für die vollständige integration der Plugins muss es natürlich auch eine Schnitstelle in den Modulen geben.
Beispiel ist noch unter:
http://forum.contenido.org/viewtopic.ph ... 944#112944
-> Ist eins der ersten Registrierungs-Module von mir mit Schnittstelle (keine Ahnung ob das auf Basis eines Moduls hier aus dem Forum ist)
Mein jetziges ist leider hart/unschön ergänzt worden müssen und somit nicht repräsentativ und wird noch überarbeitet und dann wird das HowTo auch um die Anleitung zum Integrieren von Schnittstellen in Modulen für FEU ergänzt.

mfg Oliver

barni
Beiträge: 127
Registriert: Fr 28. Okt 2005, 20:54
Kontaktdaten:

Beitrag von barni » Do 3. Jul 2008, 20:29

Ich finds total klasse und verwende das bei einer Feuerwehr Homepage zur Mitgliederverwaltung. Was allerdings noch eine tolle erweiterung wäre: Die Möglichkeit Newsletter an die Frontenduser zu schicken.

Hast du da ne Idee?

Lg Barni
ich bin genauso hilflos wie ich tu ;)

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

Beitrag von OliverL » Fr 4. Jul 2008, 07:50

Hi,

hier für müssten IMO dann ein Plugins erstellt werde um eine Verbindung von FEU und Newsleter-Empfänger (im follgenden Text RCP abgekürzt) herzustellen + DB-Tabelle.

- FEU-Plugin
- - um automatisch einen RCP zu erstellen
- - Verbindung in die neue Tabelle einzutragen
- - ein Feld für die E-Mail-Adresse die dann in den RCP gespeichert wird
- - ein Feld für die de-/aktivierung des RCP
- Tabelle würde ich "con_news_rcp_feu" nennen da der Newsletter Optional ist.

Solltest du/jemand etwas machen gilt immer:
Posten und das von anderen nochmal nachschauen/verbessern lassen
(Gerne auch die URL als PN an mich dann kann ich das Plugin hier im ersten Post verlinken so das ein Poll von Plugins entstehen kann)

mfg OliverL
Zuletzt geändert von OliverL am Fr 4. Jul 2008, 08:03, insgesamt 1-mal geändert.

barni
Beiträge: 127
Registriert: Fr 28. Okt 2005, 20:54
Kontaktdaten:

Beitrag von barni » Fr 4. Jul 2008, 08:01

Hey Oliver,

danke für deine Nachricht. Hatte es allerdings mehr als Anregung an die Community gedacht, weil dafür leider meine Programmierkenntnisse nicht ausreichen :(

Glg Barni
ich bin genauso hilflos wie ich tu ;)

former
Beiträge: 27
Registriert: So 2. Jul 2006, 19:16
Wohnort: Offenbach
Kontaktdaten:

Beitrag von former » Sa 5. Jul 2008, 09:32

Hi Oliver,

sehr gut beschrieben und funktioniert (fast) einewandfrei.
Bei mir hackt es mit der Übersetzung.
Unter 4.6.23 wurde im Backend sowie im Frontend korrekt übersetzt.
Nach einem Update auf 4.8.6 stimmt die Übersetzung lediglich am Backend.
Im Frontend bekomme ich leider nur noch die Variablennamen zu sehen.

Hat hier jemand einen Tipp für mich, woran es liegen könnte???
Die *.po Daten scheinen ja zu stimmen, da es unter 4.6.23 funktionierte.

Schöne Grüße
former

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Sa 5. Jul 2008, 14:09

Was allerdings noch eine tolle erweiterung wäre: Die Möglichkeit Newsletter an die Frontenduser zu schicken.
Nicht so, wie Du es Dir wünscht, aber das geht eigentlich schon: Die Newsletter-Module erzeugen bei Anmeldung zum Newsletter auf Wunsch automatisch auch FrontendUser, bei denen der Account identisch mit der E-Mail-Adresse ist. Bei der Erzeugung der FrontendUser werden auch die Plugins berücksichtigt.

Zugegebermaßen ist aber die weitere Verwaltung getrennt, d.h. das manuelle Löschen eines FrontendUsers löscht nicht den E-Mail-Eintrag.

Aber es gibt es relative einfache Lösung (leider habe ich gerade nicht die Zeit für den Code): Du suchst Dir ein bestimmtes Feld für die E-Mail-Adresse des Frontendusers aus und ergänzt dann in der Store-Methode Code, der automatisch über die Empfänger-Klassen (class.recipients.php) einen Empfänger erzeugt. Idealerweise sollte geprüft werden, ob der Empfänger bereits eine alte E-Mail-Adresse hatte und diese ggf. gelöscht werden.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

Beitrag von OliverL » So 6. Jul 2008, 22:45

former hat geschrieben:Im Frontend bekomme ich leider nur noch die Variablennamen zu sehen.
Hi,

wie bekommst du den die Plugins ins FE? Im Frontend funktioniert die Übersetzung nicht. Wie lädst du die Funktionen? Hast du eventuel im 4.6.23 ein Bugfix eingebaut und diesen nach dem Update in 4.8 nicht wieder ergänzt?

mfg OliverL

former
Beiträge: 27
Registriert: So 2. Jul 2006, 19:16
Wohnort: Offenbach
Kontaktdaten:

Beitrag von former » Di 8. Jul 2008, 10:37

Hi Oliver,

der Fehler ist gefunden :-)
Es hat am language_mapping gelegen. Folgender Code-Schnippsel dürfte Dir bekannt vorkommen. Hast du in einem anderen Thread mal zum Download bereitgestellt.
Der Eintrag für Version 4.8 hat gefehlt...

Code: Alles auswählen

$entity = "frontendusers";
    // i18m include for 4.6.23
    if($cfg['version'] == '4.6.23' or substr($cfg['version'],0,3) == '4.8') {
        $language_mapping = mi18n("language_mapping");
        if( $language_mapping == "language_mapping") $language_mapping = "de_DE";
        i18nInit($cfg["path"]["contenido"].$cfg["path"]["locale"], $language_mapping);
    }
Schöne Grüße,
former

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

Beitrag von OliverL » Di 8. Jul 2008, 10:51

Ähhh ...
former kann es sein das du irgendwo in einem Modul bist und nicht bei dem FEU-Plugin? Sieht stark nach den "FEU-Regist.-Modul incl. Plugin Schnittstelle" von mir aus.

Wo bei ich das "de_DE" tauschen würde in "en_EN".
Das "de_DE" kannst du bei der Modul-Übersetzung bei der Position "language_mapping" eintragen. So ist es gegeben das wenn du eine andere Sprache erstellst (z.B. RU) und das Plugin keine Übersetzungen dafür hat wenigstens die englischen Übersetzungen genommen werden.
(Ist einfach besser)

mfg OliverL

PS.: Das Registrierung-Modul usw. kommt auch noch. Aber momentan hab ich leider keine Zeit.

aSoahc
Beiträge: 49
Registriert: Fr 6. Feb 2009, 13:55
Kontaktdaten:

Re: [HowTo] Front-End-User-Plugins

Beitrag von aSoahc » Mi 11. Feb 2009, 16:08

Hallo OliverL,

was ist denn der aktuelle Stand bei deinem Front-End-User-Plugin?
Ich würde es gern einsetzen. Allerdings ist es immer schwer 2 parallele Thread-Trees zu verfolgen, besonders wenn sie bereits etwas älter sind.

Gruß aSoahc

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

Re: [HowTo] Front-End-User-Plugins

Beitrag von OliverL » Mi 11. Feb 2009, 16:21

Der Stand der Plugin-Schnittstelle ist immer noch der gleiche.
Ich biete hier im Thread kein Plugin an sondern die Informationen die dafür nötig sind um selber welche zubauen.
-> [HowTo] ....

Im anderen Thread habe ich mal gezeigt das man die Plugins auch in seine Module einbinden kann und wie diese Schnittstelle im Modul aussehen kann.

mfg OliverL

Gesperrt