Beiträge der Kategorie TYPO3

Extension pro_industrydb

Geschrieben von npostnik in TYPO3 am 1. Juli 2008

Im Moment habe ich keine Zeit zum Schreiben von typo3 Einträgen. Es passiert schon sehr viel, ich habe einige Sites an denen ich arbeite, aber irgendwie kommt momentan kein Material für einen Eintrag zusammen. Dafür passiert in letzter Zeit einiges mit meiner Extension pro_industrydb. Zum einen gibt es Weiterentwicklungswünsche, da komme ich leider nicht zu. Zum anderen gibt es auch mal Lob und Feedback. Das freut mich sehr, denn ich finde diesen ganzen Communitygedanken einfach grossartig und freue mich, wenn andere Leute von meiner Arbeit profitieren.
Jetzt gabs auch mal ein Update mit ein paar Fixes. Ich würde mich sehr darüber freuen, wenn meine Extension genutzt wird und dazu ein paar Kommentare verfasst werden.

Bild aus dem Header als Hintergrund verwenden

Geschrieben von npostnik in TYPO3 am 12. Juni 2008

Manchmal ist es notwenig, Bilder aus dem Media-Feld der Seite als Hintergrund zu verwenden, gelegentlich als Gifbuilder-Objekt. Dieses Beispiel rendert das Bild aus dem Media-Feld, versieht das ganze mit dem Untertitel/Titel der Seite und fügt noch ein farbiges Rechteck hinzu. Anschließend wird das ganze als Hintergrundbild in einen div mit der Id „header“ eingefügt. Vorteil dieses Verfahrens ist, dass der Header semantisch richtig und nicht als Bild dargestellt wird.

temp.header = COA
temp.header {
1 = TEXT
1.field = media
1.listNum = 0
1.wrap =

5 = TEXT
5.field = subtitle//title
5.wrap =

|

10 = HTML
10.value =

15 = IMAGE
15.file = GIFBUILDER
15.file {
XY = 680,210
backColor = #999999
transparentBackground = 1
10 = TEXT
10.text.field = subtitle
10.text.listNum = 0
10.text.listNum.splitChar = |
10.fontColor = {$colorWhite}
10.fontSize = {$font.sizeHeaderSmall}
10.fontFile = {$font.headerSmall}
10.offset = 460,118
20 < .10 20.text.listNum = 1 20.fontSize = {$font.sizeHeaderBig} 20.fontFile = {$font.headerBig} 20.offset = 200,155 5 = BOX 5.dimensions = 0,120,300+[20.w],40 5.color = {$color80} 7 = BOX 7.dimensions = 0,160,485,60 7.color = {$color100} } 80 = HTML 80.value =

}

Redirect nach Login/Logout in newloginbox

Geschrieben von npostnik in TYPO3 am 22. Mai 2008

Problem: nach dem Login/Logout soll man auf einer bestimmten Seite landen, das Formular zu einloggen befindet sich jedoch auf allen Seiten. Oder man hat eine Vorschaltseite mit Sprachauswahl und wenn man eingeloggt in einem geschlossenen Bereich surft und sich dann ausloggt, dann landet man auf eben dieser Vorschaltseite, was nicht schön ist.
Das Loginformular kann über das Template in TypoScript inkludiert werden oder auch als ein Content-Element von einer bestimmten Seite eingefügt werden. Hauptsache über TypoScript, geht auch nicht anders, wenn man es auf jeder Seite haben möchte.
Es gibt im Template für newloginbox ein verstecktes Feld mit dem Namen redirect, das Problem ist, dass es leer ist. Es gibt einige Extensions, die eine Umleitung anbieten, das Problem ist, dass die Seite auf die umgeleitet wird, im GET-Parameter angegeben werden muss. Das ist manchmal schwierig. Oder es gibt eine Extension, auf der man dem Benutzer oder der Gruppe eine Seite zuweisen kann, das löst aber nicht das Problem beim Logout.
Meine Lösung ist daher: Aus dem Template den Form-Tag entfernen (mit Start- und Endtag) und das versteckte Feld zum Redirect. Dann das Feld über TypoScript wieder hinzufügen. Das Loginformular kann man als COA aufbauen. 10 ist der Form-Starttag, 20 die newloginbox, 30 das versteckte Feld und 40 der schließende Formtag. Über typolink kann man die URL in das Action-Attribut im Form-Tag und in das Value-Attribut des versteckten Feldes reinschreiben. Über Conditions definiert man dann einen anderen Wert im Action-Attribut, wenn jemand sich ausloggt, so kann man die Benutzer dann auf eine bestimmte Seite schicken. Ungefähr so…

temp = COA
temp.10 = TEXT
temp.10.typolink.parameter.data = TSFE:id
temp.10.typolink.returnLast = url
temp.10.typolink.wrap =

Vererbung der Metatags mit metatags (extended)

Geschrieben von npostnik in TYPO3 am 18. März 2008

Die Extensions metatags ermöglicht es globale Metatags im TypoScript zu definieren, die auf allen Seiten im Header erscheinen. Man kann diese Tags aber auch in der Seite selbst angeben, dabei werden die globalen überschrieben. Das Problem ist, dass die Extension selbst keine Metatag-Vererbung mitbringt, d.h. es werden Metatags nur von der aktuellen Seite genommen. Vielleicht aber möchte man in einem Seitenbaumteil andere Metatags definieren, da möchte man nicht gleich ein Extension-Template anlegen.
Die Tags werden mit einer einer TypoScript konfiguration aus der aktuellen Seite gelesen. Dabei ist das Element vom Typ stdWrap und ist somit sehr flexibel. Hier das Original zum Auslesen der Keywords und Description aus der aktuellen Seite:

plugin.meta.local.description.field = description
plugin.meta.local.keywords.field = keywords

Damit man die Keywords bzw. Description von der übergeordneten Seite vererben lassen kann, muss man auf die Eigenschaft data im stdWrap zurückgreifen und das field löschen, da es den Wert in data überschreibt.

plugin.meta.local.description.field >
plugin.meta.local.keywords.field >
plugin.meta.local.description.data = levelfield:-1, description, slide
plugin.meta.local.keywords.data = levelfield:-1, keywords, slide

Damit diese Eigentschaften zur Verfügung stehen, muss man über Install-Tool die Felder keywords und description zu [FE][addRootLineFields] hinzufügen. Wäre soweit fertig, wenn die Extension die headerData nicht selbst am Anfang einbinden würde, was die ganzen Änderungen von eben zunichte macht. Daher muss man nach der „Neukonfiguration“ die headerData erneut zuweisen:

page.headerData.999 < plugin.meta

Druckversion mit TemplaVoila

Geschrieben von npostnik in TYPO3 am 4. März 2008

Die Druckversion der Seite kann über 3 mögliche Wege gesteuert werden. Der erste ist das Einbinden eines Stylesheets mit der media-Attribut „print“. Da kann man bestimmte Bereiche ausblenden, wie z.B. Menü. Der Nachteil ist, dass es nicht in allen Browsern funktioniert könnte und im Hinblick auf Typo3-Performance muss einiges für die Seite gerendert und gerendert werden, was dann nicht angezeigt wird. Die zweite Möglichkeit ist das Type-Attribut in Typo3. Da kann man bestimmte Elemente bereits in Typo3 ausgeben oder die Seite komplett anders gestalten. Der Nachteil ist, dass es mit TemplaVoila nicht funktioniert, sobald man FCEs benutzt. Die dritte Möglichkeit ist über die Übergabe der GET-Variable print, die TemplaVoila dazu veranlaßt, ein anderes Template zu verwenden (falls eins definiert ist). In diesem Beispiel werden alle drei Methoden miteinander verknüpft.

Drucken Link mit TypoScript anlegen

Zunächst definiert man den Link in TypoScript im Haupttemplate, damit er auf jeder Seite angezeigt wird:

lib.specialnavigation {
30 = TEXT
30 {
value = Seite drucken
wrap =

stdWrap.typolink.parameter.data = TSFE:id
stdWrap.typolink.parameter.wrap = |,98 710×600
stdWrap.typolink.addQueryString = 1
stdWrap.typolink.additionalParams = &print=1&no_cache=1
stdWrap.typolink.JSwindow_params = status=0,menubar=0,scrollbars=1,location=0,toolbar=0
}
}

Die Druckversion geht in einem neuen Fenster auf. Die URL dazu ist die aktuelle Seite (mit allen Parametern, ergibt sich aus addQueryString) mit einem anderen Page Type (98) und den zusätzlichen Variablen print und no_cache. Nun kann man im TypoScript-Template die Druckversion mit typeNum 98 definieren und da ein anderes Stylesheet angeben und einen anderen Header. Hier ist ein Beispiel für eine Toolbar, die das Drucken de Dokuments und das Schließen des Fensters ermöglicht.

print = PAGE
print {
bodyTag =
typeNum = 98
includeCSS {
print = {$templateRoot}/css/print.css
print2 = {$templateRoot}css/print2.css
print2.media = print
}
10 = TEXT
10.value =

20 = TEXT
20.value = |

# site and page title
40 = HTML
40.value =

49 = HTML
49.value =

50 = USER
50.userFunc = tx_templavoila_pi1->main_page
51 = HTML
51.value =

}

Gleichzeitig soll diese Toolbar nicht gedruckt werden. Daher wird ein weiteres Stylehsheet mit dem Attribut media=“print“ eingebunden, das diese Toolbar wieder ausblendet beim tatsächlichen Druck.

Template für Druckversion anlegen

Zunächst bereitet man die HTM-Datei vor. Da legt man eine neue Datei an oder kopiert den Inhalt der HTML-Datei, die als Vorlage dient. Dort entfernt man alle Teile, die in der Druckansicht nicht benötigt werden und ordnet die anderen so an, wie gewünscht. Ein Beispiel: das Haupttemplate hat Elemente wie Suchbox, Loginbox, Rootline, Login-Status-Anzeige, Footer und Navigation, die alle in der Druckversion nicht benötigt werden. Übrig bleiben Subcontent links und Maincontent in der Hauptspalte. Diese Inhalte können aber auch untereinander angeordnet werden.

In der Listenansicht im Seitenbaum die Seite mit den TemplaVoila Objekten auswählen. Dann legt man ein neues Template Object (TO) an. Als Titel vergibt man sinnvollerweise irgendwas, was auf Drucken hindeutet (Beispielseite Main Template Print). Dann wählt man im Drop-Down-Menü unter „Make this a sub-template of“ (deutsch bitte selber denken) das Template aus, zu dem dieses das Druckäquivalent sein soll, also in diesem Fall „Beispielseite Main Template“. In dem Feld „file reference“ wählt man im Datei-Browser die vorher erstellte HTML-Datei aus. Zuletzt wählt man im Feld „select a type of rendering“ „printer friendly“ aus und speichert ab.

Zum Testen kann man die Druckversion über den Link im FE aufrufen, wenn eine Fehlermeldung angezeigt wird (irgendwas mit falschem Mapping), dann ist alles prima.

Dann klickt man (immer noch in der Listenansicht) auf das Symbol des eben erstellten Template Objects, so dass das Context-Menü erscheint und wählt da „TemplaVoila“. Man gelangt direkt auf die Mapping-Einstellungen des TO. Als Data Structure wird das DS des übergeordneten Template benutzt. Also sieht man in den Mapping-Einstellungen alle Elemente, die im übergeordneten Template gemappt werden. Da braucht man aber nicht alle. Also mappt man nur die, die man für die Druckversion braucht: ROOT, Maincontent, Maincontent SubColumn und Subcontent. Dann noch im FE testen.

Ergebnis: Die Druckversion wird in einem neuen Fenster geöffnet. Oberhalb wird eine Toolbar und ein Logo dargestellt. Die Toolbar wird beim tatsächlichen Drucken wieder ausgeblendet. Durch den GET-Parameter print wird TemplaVoila dazu veranlaßt, ein anderes Template für die Druckversion zu verwenden.

Schicke Input-Buttons und Links

Geschrieben von npostnik in css, TYPO3 am 28. Februar 2008

Einen Input-Button zu stylen ist an sich nicht so schwer, die Probleme entstehen dann, wenn man es in mehrern Browsern (Firefox, IE6 und IE7) gleich haben möchte. Außerdem sollten die Buttons skalierbar sein und trotzdem einen schönen Hintergrund haben.
Dazu habe ich erstmal eine Klasse definiert, die für input-Buttons und Links gleichermaßen gelten sollte und darin folgendes definiert:

padding: 2px 30px 2px 10px;
border: 0 none;
background: #fff url(’schicke_buttons/submit_button_green.gif‘) top right no-repeat;
cursor: pointer;
font-weight: bold;
margin-top: 5px;
margin-bottom: 5px;
outline: 0 none;
color: #555555 !important;

Die Eigenschaft padding passte aber nicht für Links, daher wird sie ein wenig angepasst. Gleichzeitig wird für Links ein Rand links definiert, was dem Button sein endgültiges Aussehen gibt. Damit wäre man erstmal mit allem fertig, wenn da nicht der IE wäre. Dieser gibt dem Button, sobald man irgendwie die Eigenschaft border setzt, einen Rand, und zwar häßlich und an allen Seiten.
Daher wird der Rand nur für den „unproblematischen“ Browser Firefox definiert mit einem Selector, den der IE7 nicht versteht (html>body kann der mittlerweile auch).
Da man dem Input-Button im IE nicht einfach einen Rand geben kann aus dem eben genannten Grund, muss man sich mit einem Span drumrum gehelfen. Dieser Span definiert den Rand links neben dem Feld und löst gleichzeitig das Problem mit dem 3px-floating-bug.
Wenn man diese schicken Buttons in Typo3 benutzen möchte, besteht das Problem, dass die Formulare automatisch generiert werden und man keine Möglichkeit hat, einen Span um den Button einzufügen. Daher habe ich kleines Skript geschrieben, das diesen Span automatisch um einen Mailform-Button packt. So sollten die Buttons in allen Browsern aussehen, und hier ist das Beispiel zum Anschauen.

User Registrierung erweitern

Geschrieben von npostnik in TYPO3 am 12. Februar 2008

Zu der Benutzerregistrierung sr_feuser_register sollten neue Felder dazukommen. Wie also in der Dokumentation zu der Extension beschrieben habe ich mit der EM mit dem Kickstarter eine neue Extension angelegt. Diese Extension konnte nichts anderes außer neue Felder in der Tabelle fe_users anzulegen. Da die vom Kickstarter automatisch generierten Spaltennamen zu lang sind, hab ich sie ein wenig geändert. Nach der Einrichtung und der Installation hatte die Extension die Tabelle um einige Felder erweitert: ein Eingabefeld, ein Auswahlfeld (Checkbox), einige Textfelder (längere Texte) und eine Drop-Down-Box (Auswahl).
Dann musste man nun noch das Template um die Felder erweitern und die Felder in die Konstanten reinschreiben, damit sie auch angezeigt werden.

Dann habe ich festgestellt, dass die Extension sr_feuser_register keine Ansicht bietet, es gibt ein Bearbeitungsformular, ein Formular zum Anlegen eines Accounts, aber keine Einstellung, um die gespeicherten Daten einfach nur anzuzeigen. Die Idee war, die eben angelegte Extension zu erweitern zu einem Frontend Plugin.
Im Kickstarter hatte ich die entsprechenden Einstellungen vorgenommen: Frontend Plugin als Typ und wieder neu schreiben lassen. Da ich die Spaltennamen vorher geändert hatte, musste ich die aus der alten Datei kopieren oder wieder ändern.

Man muss ja nichts neu erfinden: die Felder, die angezeigt werden sollen und das Template liefert ja schon sr_feuser_register, den Pfad zum Template sollte der Benutzer auch nicht zweimal eingeben müssen. Da diese Definition aber in den Konstanten steht, kann man einfach im Setup der eigenen Extension darauf zugreifen und verfügbar machen.

plugin.tx_npptafeuserregister_pi1 {
# copy stuff you need from sr_feuser_register
formFields = {$plugin.tx_srfeuserregister_pi1.formFields}
templateFile = {$plugin.tx_srfeuserregister_pi1.file.templateFile}
}

Dann sucht man sich aus dem Template von sr_feuser_register einen Teil aus, der gut passt, z.B. TEMPLATE_CREATE_PREVIEW. Dort stehen die Daten nicht in Input-Feldern, sondern einfach mit Labels untereinander. Das einzige was ein wenig stört, ist das Formular und die Buttons, aber wozu gibt es reguläre Ausdrücke?
Die Beschriftung der Buttons kann man auch von der sr_feuser_register „klauen“. Dazu brauche ich aber eine Instanz dieser Klasse, lade dort die Locallang rein und lasse mit die Labels übersetzen.
Weiterer Trick (danke Boris) ist die Locallang für die TCA reinzuladen und die Int-Werte durch die dazugehörigen Labels ersetzen zu lassen. Anschließend werden die unnötigen Labels entfernt.

// Klassenvariable
var $originalTemplateCode;
function main($content,$conf) {
global $TCA;
$this->conf=$conf;
$this->pi_setPiVarDefaults();
$this->pi_loadLL();

$this->getTemplateCode();

$srpath = t3lib_extMgm::extPath(’sr_feuser_register‘);
$srpath.= ‚pi1/class.tx_srfeuserregister_pi1.php‘;
require_once($srpath);
$srclass = t3lib_div::makeInstance(‚tx_srfeuserregister_pi1′);
$srclass->pi_loadLL();

$dbllfile = file_get_contents(t3lib_extMgm::extPath($this->extKey).’locallang_db.xml‘);
$dbllfile = t3lib_div::xml2array($dbllfile);
$dbll = $dbllfile[‚data‘][‚default‘];
if($dbllfile[‚data‘][$this->LLkey]) {
$dbll = array_merge($lang,$dbllfile[‚data‘][$this->LLkey]);
}

$templateCode = $this->cObj->getSubpart($this->originalTemplateCode,’###TEMPLATE_CREATE_PREVIEW###‘);

$feuser = $GLOBALS[‚TSFE‘]->fe_user->user; // get the fe user

// replace markers
$fields = explode(‚,‘,$this->conf[‚formFields‘]);
$markerArray = array();
for($i=0;$ipi_getLL($key,$dbll[‚fe_users.‘.$key]);
}
}
$key = ‚pta_job‘;
$value = $feuser[$key];
$markerArray[‚###TCA_INPUT_‘.$key.’###‘] = $dbll[‚fe_users.‘.$key.‘.I.‘.$value];

// remove useless labels
$markerArray[‚###HIDDENFIELDS###‘] = “;
$markerArray[‚###LABEL_V_DEAR###‘] = “;
$markerArray[‚###LABEL_V_VERIFY_BEFORE_CREATE###‘] = “;

// remove form and input tags from template
$search = ‚//i‘;
$templateCode = preg_replace($search,“,$templateCode);
$search = ‚/<\/form>/i‘;
$templateCode = preg_replace($search,“,$templateCode);
$search = ‚//i‘;
$templateCode = preg_replace($search,“,$templateCode);

$content = $this->cObj->substituteMarkerArray($templateCode,$markerArray);

$removeFields = array(‚gender‘,’name‘,’status‘,’date_of_birth‘,’title‘,’company‘,’title‘,’address‘,’city‘,’zone‘,’static_info_country‘,’country‘,’zip‘,’telephone‘,’fax‘,’usergroup‘,’module_sys_dmail_category‘,’module_sys_dmail_html‘,’language‘,’www‘,’image‘,’comments‘);
for($i=0;$icObj->substituteSubpart($content,’###SUB_INCLUDED_FIELD_‘.$key.’###‘,“);
}
}
return $this->pi_wrapInBaseClass($content);
}

function getTemplateCode() {
$this->originalTemplateCode = $this->cObj->fileResource($this->conf[‚templateFile‘]);
}

Locallang mit TypoScript überschreiben

Geschrieben von npostnik in TYPO3 am 12. Februar 2008

Prinzipiell ja nicht schwieriges und häufig in Foren gefragt und in Tutorials erklärt. 08/15 Lösungen sind vielleicht gut, aber solche Tutorials („so und so, ist doch ganz einfach“) bringen manchmal einfach nicht weiter.
In meinem Fall hatte ich eine Erweiterung der Extension tipafriend geschrieben. Hier beschreibe ich, wie es geht.
https://www.npostnik.de/typo3/extension-per-xclass-erweitern-tipafriend/

Nun hatte ich in der Erweiterungsklasse ein Template mit Markern benutzt und mit Locallang die Sprachsteuerung gemacht (nicht wie vorher übers Template). Einige Sprach-Labels waren nun so spezifisch, dass ich diese Änderungen nicht in der locallang.xml vornehmen wollte, also überschreibt man die Labels per TypoScript, aber wie? Die Abweichung von der „Norm“ sind folgende:
– die Extension tipafriend hat schon TyposCript-Konfiguration, diese steht aber anstatt in plugin.tx_tipafriend_pi1 einfach nur in plugin.tipafriend
– meine Erweiterungsextension heißt np_tipafriend_ext, die Klasse heißt aber ux_tx_tipafriend, die ursprüngliche Klasse heißt tx_tipafriend
– meine Erweiterungs-Klasse liegt nicht in einem pi1 Ordner

Dann hatte ich alles ausprobiert, mit ux_tx_tipafriend_pi1, mit tx_nptipafriendext, mit ux_tx_tipafriend, sogar die Variation von _LOCAL_LANG ohne Unterstrich am Anfang.
Die Lösung ist einfach (wenn mans weiß): Es gab ja schon Plugin-Konfiguration in TypoScript für die ursprüngliche Erweiterung, diese musste man nur noch um die Sprach-Labels erweitern, also:

plugin.tipafriend._LOCAL_LANG.de.formComment = Wenn Sie diese Seite als Link an eine(n) Freund(in) oder eine(n) Kollegin/en versenden möchten, füllen Sie bitte die unten stehenden Felder aus.

Ach ja, hier sind ein paar 08/15 Beispiele:

plugin.tx_newloginbox_pi1._LOCAL_LANG.de.oLabel_header_logout = Sie haben sich abgemeldet
plugin.tx_indexedsearch._LOCAL_LANG.de.pi_list_browseresults_page =
plugin.tx_indexedsearch._LOCAL_LANG.de.res_size = Relevanz:

Anpassungen am kb_mahjongg

Geschrieben von npostnik in TYPO3 am 8. Februar 2008

Beim Spiel kb_mahjongg soll die Auswahl der Tilesets und Layouts nicht angezeigt werden, vielmehr ist nur ein Spiel möglich. Es müssen aber zwei Variablen gesetzt werden, nämlich die Tileset-ID und die Layout-ID. Da musste ich zu einem blöden Mittel zurückgreifen – das Pfuschen im Quellcode. In der Datei pi2/class.tx_kbmahjongg_pi1.php habe ich vor den ganzen Abfragen einfach folgendes eingefügt:

$this->layout_uid = intval($this->piVars[‚layout‘]);
$this->tileset_uid = intval($this->piVars[‚tileset‘]);
/* NEU */
$this->layout_uid = $this->conf[‚layout_uid‘];
$this->tileset_uid = $this->conf[‚tileset_uid‘];
/* bis hier */
$this->layouts = $this->funcs->getLayouts();
$this->tilesets= $this->funcs->getTilesets();

Jetzt muss man im Template-Setup die Variablen einfügen:

plugin.tx_kbgamemahjongg_pi2.layout_uid = 1
plugin.tx_kbgamemahjongg_pi2.tileset_uid = 1

Damit startet man mit dem Default-Tileset.

Nun soll ein neues Tileset und ein neues Layout dazukommen, ein möglichst einfaches. Dazu kopiere ich das Default-Tileset, füge es neu ein (neue ID z.B. 2) und benenne einige Sachen um, vor allem ändere ich die Datei, aus der das eingelesen wird. Das gleiche mache ich mit dem Layout.

Dann will ich ein einfaches Spiel machen, nur mit 60 Steinen anstatt mit 144. Dazu müssen im Layout und im Tileset Anpassungen vorgenommen werden. Zunächst bearbeite ich das Tileset: alles entfernt bis auf circle_1 bis circle_5, character_1 bis character_5 und bamboo_1 bis bamboo_5. Das sind insgesamt 60 Steine. Das Layout muss auch entsprechend angepasst werden, sonst wird das Spiel nicht gestartet. In der ersten Ebene liegen 8 x 5 Steine, dann mittig darauf ein Block aus 4 x 5 Steinen, das sind auch 60. Die Layoutdatei sieht wie folgt aus: 0 2 0, 0 4 0 bis 0 16 0, 2 2 0, 2 4 0 bis 2 16 0 etc. bis 8 16 0. Das ist die erste Ebene. In der zweiten stehen Zahlen 0 6 1, 0 8 1, 0 10 1, 0 12 1 etc. bis 8 12 1.

Die Dateien dann abspeichern und dem Layout und Tileset entsprechend neu zuweisen. Jetzt fehlt nur noch die TypoScript Konfiguration für das Spielfeld. Die einfachste Variante ist, die default Werte zu kopieren. Wenn Layout und Tileset beide z.B. easyLayout bzw. easyTileset heißen, dann reicht folgendes im Template:

plugin.tx_kbgamemahjongg_pi2.easyLayout < plugin.tx_kbgamemahjongg_pi2.default plugin.tx_kbgamemahjongg_pi2.easyLayout.easyTileset < plugin.tx_kbgamemahjongg_pi2.default.default

Extension per XCLASS erweitern (tipafriend)

Geschrieben von npostnik in TYPO3 am 29. Januar 2008

Bei fast jeder Extension findet man am Ende einen Abschnitt, der es ermöglicht diese Extension zu erweitern, bzw. die Funktionen für eigene Zwecke zu überschreiben. Das hat den Vorteil, dass man der eigentlichen Quellcode nicht ändert und so bei einem Update nichts überschrieben werden kann.
In einem kurzen Beispiel werde ich die Extension tip-a-friend erweitern, so dass einige ungünstige Fehler behoben werden.

Zunächst muss ein Ordner angelegt werden, dass die neue Extension beherbergen soll, diese soll np_tipafriend_ext heißen. Das _ext deutet darauf hin, dass die Extension eine Erweiterung ist, der Name der erweiterten Extension tipafriend steckt im Namen auch drin.
Dann öffnet man die Klassen-Datei der Extension, die man erweitern will und sucht ganz unten den Abschnitt mit der XCLASS. Bei tip-a-friend nämlich:

if (defined(‚TYPO3_MODE‘) && $TYPO3_CONF_VARS[TYPO3_MODE][‚XCLASS‘][‚ext/tipafriend/pi/class.tx_tipafriend.php‘]) {
include_once($TYPO3_CONF_VARS[TYPO3_MODE][‚XCLASS‘][‚ext/tipafriend/pi/class.tx_tipafriend.php‘]);
}

Um nun die neue Extension als Erweiterung der tip-a-friend in Typo3 zu registrieren, legt man im neuen Extension-Ordner die Datei ext_localconf.php an und schreibt dort folgendes hinein:

if (!defined (‚TYPO3_MODE‘)) die (‚Access denied.‘);

$TYPO3_CONF_VARS[‚FE‘][‚XCLASS‘][‚ext/tipafriend/pi/class.tx_tipafriend.php‘] = t3lib_extMgm::extPath($_EXTKEY).’class.ux_tx_tipafriend.php‘;

Der erste Teil entspricht dem Ausdruck entnommen aus der Tip-a-friend Klassen-Datei, der zweite gibt an, wie die Klasse der neuen Extension lautet. Dieser muss einem bestimmten Schema folgen: dem Klassennamen der zu erweiternden Extension wird ein ux_ vorgestellt! Falls der Klassenname tx_ahlinklist_pi1 lautet, dann ist die Erweiterung ux_tx_ahlinklist_pi1.

Dann legt man eine Datei an, die den mit ux_ beginnenden Dateinamen trägt. Direkt im Ordner der Extension gibt es nun einen Datei, die class.ux_tx_tipafriend.php heißt und (ohne Kommentarblock) folgenden Code enthält:

class ux_tx_tipafriend extends tx_tipafriend {
function main_tipafriend($content,$conf) {
return „HIER“;
}
}

Die Hauptfunktion der Tip-a-friend heißt nämlich main_tipafriend (bei den meisten Extensions einfach nur main), daher wird in der neuen Klasse die Funktion überschrieben und liefert „HIER“ zurück. Man kann die Funktionen der übergeordneten Klasse aufrufen mit parent::Funktionsname, das Ergebnis dann bearbeiten und zurückgeben.

[dsgvo_imprint]

Beiträge der Kategorie TYPO3

Extension pro_industrydb

Bild aus dem Header als Hintergrund verwenden

|

Redirect nach Login/Logout in newloginbox

Vererbung der Metatags mit metatags (extended)

Druckversion mit TemplaVoila

Schicke Input-Buttons und Links

User Registrierung erweitern

Locallang mit TypoScript überschreiben

Anpassungen am kb_mahjongg

Extension per XCLASS erweitern (tipafriend)

Seiten

Neueste Kommentare

Blogroll

Links

Meta