Wikizone - Benutzerbeiträge [de]

Typo3 - Extensions programmieren

2006-07-06T11:43:07Z

84.161.146.115:

== Struktur einer Extension ==
'''ext_emconf.php'''

Informationen und Metadaten zur Extension. Etwa die Infos die im Kickstarter unter General Info stehen.

* Root-Verzeichnis
**'''ext_localconf.php''' Enthält Konfigurationsdaten ($TYPO3_CONF_VARS) für das Backend und Frontend. Hier kann über die Extension API auch TypoScript eingebunden werden.
**'''ext_tables.php''' Konfiguration von Datenbanktabellen. Plugins und Module üver die Extension API einbinden. (Alles über Kickstarter)
**'''ext_tables.sql''' SQL-Daten für die Tabellendefinition. Die Auswertung erfolgt über den Extension Manager und das Install-Tool.
**'''ext_tables_static+adt.sql''' SQL-Tabellendefinition inkl. Daten. Z.B. für statische Daten (Länderinfos etc.)Die Tabellen müssen zusätzlich in ext_tables.sql definiert sein.
**'''ext_typoscript_*.txt''' Globaler TypoScript-Code. Steht nicht üver Template-Datensätze zur Auswahl (siehe /static)
**'''ext_conf_template.txt''' Hier werden Optionen zur Konfiguration angelegt, die der Benutzer im Extensionmanager einstellen kann.
**'''*icon*.gif''' Symbol-Dateien für Extension,DB-Tabellen,Plugins, Module...
**'''locallang*.php''' Texte für die Lokalisierung in verschiedenen Sprachen
**'''class.ext_update.php''' Funktionen für ein Update der Extension (Beispiel siehe newloginbox).

*'''pi1/''' Verzeichnis für Skripte und Daten des Plugin
**'''class*.php''' PHP-Klassen z.B. für Plugins oder Submodule

*'''cm1/''' Verzeichnis für Dateien die das Kontext-Menü betreffen

*'''mod1/''' Verzeichnis für ein Modul.
**'''conf.php''' Konfigurationsdatei für ein Modul zum einbinden ins Backend.
**'''index.php''' Hauptscript eines Moduls.

*'''modfunc1/''' Skripte und Daten für Submodul-Funktionen

*'''static/''' TypoScript-Template-Dateien. Diese werden über die Extension-API eingebunden und stehen dann in Template-Datensätzen, ähnlich den Standard Templates zur Auswahl.

*'''sv1/''' Verzeichnis für Services

*'''res/''' Verzeichnis für beliebige 'recourcen'.

*'''doc/''' Verzeichnis der Dokumentation.

== Wo werden Extensions installiert ? ==
===typo3/sysext/ (System)===
System Extensions wie cms und lang. Hier können keine Extensions mit dem Extension Manager installiert werden.
===typo3/ext/ - globale Extensions (Global) ===
Z.B. diese die von Typo3 mitgeliefert werden. Mit der Option allowGlobalInstall kann man die Installation in dieses Verzeichnis erlauben. Das ist dann nicht sinnvoll wenn sich mehrere Typo3 WEbsites eine Installation teilen, weil es hier zu Versionskonflikten kommen kann.
===typo3conf/ext - lokale Extensions (Local)===
Hier werden normalerweise alle Extensions installiert. Die Lokale Installation hat immer Vorang vor einer globalen.

== Typolinks richtig in Extensions einsetzen ==

In diesem kurzem Tutorial möchte ich zeigen, wie man Typolinks in eigenen Erweiterungen erstellt, die das
Feature 'Simulate Static Documents' unterstützen und eine Ausgabe erstellen, die von Typo3 gecached wird
und so auch mit der Indexed search verwendet werden können. Diese Informationen wurden aus anderen
Erweiterungen zusammengetragen, speziell aus der Erweiterung tt_board.
Typoscript
Zuerst erstelle in der Datei 'ext_typoscript_setup.txt' eine Eigenschaft, die deiner Erweiterung mitteilt, ob
caching genutzt werden soll oder nicht:

<pre>
plugin.tx_myextension_pi1 {
allowCaching = 1
}
</pre>

Wenn das später auf 0 gesetzt wird, werden diese Seiten nicht mehr gecached.

'''Vorbereitung'''

Bereite in der main() Funktion den Typolink vor und konfiguriere das caching:

<pre>
class tx_myextension_pi1 extends tslib_pibase {
...
var $allowCaching = "";
function main($content,$conf) {
$this->conf=$conf;
...
// Preconfigure the typolink
$this->local_cObj = t3lib_div::makeInstance("tslib_cObj");
$this->local_cObj->setCurrentVal($GLOBALS["TSFE"]->id);
$this->typolink_conf = $this->conf["typolink."];
$this->typolink_conf["parameter."]["current"] = 1;
$this->typolink_conf["additionalParams"] =
$this->cObj->stdWrap($this->typolink_conf["additionalParams"],
$this->typolink_conf["additionalParams."]);
unset($this->typolink_conf["additionalParams."]);
// Configure caching
$this->allowCaching = $this->conf["allowCaching"]?1:0;
if (!$this->allowCaching) {
$GLOBALS["TSFE"]->set_no_cache();
}
...
}
}
Links erstellen
Um nun Links in der Erweiterung zu erstellen, benutze das folgende Code Fragment:
$temp_conf = $this->typolink_conf;
$temp_conf["additionalParams"] .= "&tx_myextension_pi1[key]=value";
$temp_conf["useCacheHash"] = $this->allowCaching;
$temp_conf["no_cache"] = !$this->allowCaching;
$the_link = $this->local_cObj->typolink("Linktext", $temp_conf);
</pre>

Danach kann man '$the_link' zu der Ausgabe hinzufügen. Das '$temp_conf' Array kann man mit allen
Eigenschaften des typolink Objektes erweitern.

Tutorial by typo3.hachmeister.org
Von:fruit-lab.de

== Debug Methode ==
Typo3 | Debug Methode :: Hilfe bei der Programmierung

Wenn man eine eigene Extension schreibt benutzt man zum größten Teil Array, und um den Überblick zu
behalten was nach den ganzen schritten in einem Array noch so drin steht hat man die möglichkeit mit einer Funktion das Array schön und sauber in einer tabelle anzeigen zu lassen.

'''Beispiel:'''
<pre>
$data = array("Name" => "Peter KeineAhnung", "Alter" => 22, "Wohnort" => "Ratingen");
echo t3lib_div::debug($data);
</pre>

Ergebnis:

[[Bild:TS_debug01.gif]]

je nach devIPMask Einstellungen ist auch nur
debug($sonstwas);
nützlich, vor allem wenn ein Kundenprojekt Online isteinfach im Installtool und devIpMask deine IP eingeben und dann mit debug($sonstwas); arbeiten, so kannst nur du den debug sehen und nicht irgendwelche User die grade auf der Site sind.

Kleiner Zusatz Tip:

Ihr lasst euch gleichzeitig mehrere Debugs ausgeben und verliert den überblick welcher debug welcher ist...

'''Beispiel'''

Ihr lasst euch ein Array vor einer funktion debugen und anschliessend...
da habt ihr dann die möglichkeit euerem Debug einen Namen zu geben..

'''Beispiel:'''
<pre>
$data = array("Name" => "Peter KeineAhnung", "Alter" => 22, "Wohnort" => "Ratingen");
echo t3lib_div::debug($data,'Array vorher');
$data['Name'] = 'T.uX';
$data['Alter'] = 32;
echo t3lib_div::debug($data,'Array nachher');
</pre>

Ergebnis:

[[Bild:TS_debug02.gif]]

Hinweis:
läst du dir eine Variable im debug ausgeben erscheint [b]|debug|[/b]. das funzt nur mit Arrays ;-)
Auch bei der Verwendung der integrierten DB-Abstrktionsschicht können eine Reihe von Fehlern auftreten,
die teilweise nur sehr magere Fehlermeldungen produzieren. Um eine etwas explizitere Fehlerausgabe zu
erzwingen sollte man folgende Zeile in seine Extension integrieren*:
$GLOBALS['TYPO3_DB']->debugOutput = true;

So wird z.B. das SQL-Stement Ausgegeben, das zu einem Fehler geführt hat.
Tutorial by typo3.kj187.de

== PHP-Skripte einbinden ==
Typo3 | Externe PHP Scripte einbinden

Haben Sie ihr Projekt auf Typo3 umgestellt und wollen dennoch ihre eigenen PHP-Scripte verwenden? Dann machen Sie folgendes.

Schreiben Sie in das SETUP Feld des Templates:

<pre>
tt_content.script = CASE
tt_content.script {
key.field = select_key
test = PHP_SCRIPT_EXT
test.file = fileadmin/dein_script.php
}
</pre>

Um das Script jetzt als Contentelement in die Seite einzubinden, legen Sie einen neuen Seiteninhalt an. Wechseln Sie von Typ = Text auf Typ = Skript. In das CODE Feld müssen Sie jetzt nur noch test eintragen und sie sind fertig.

Dies ist die einfachste Methode. Die Ausgabe des Scripts wird aber nicht in den Cache aufgenommen! Diese Funktion wird leider nicht unterstützt.

Tutorial by typo3.kj187.de

Anmerkung Steff: Für die Cache Funktion kann man z.B. eine Einfache Extension basteln.

== Beispiele ==
===Einträge aus Bildausrichtungen im Backend entfernen===
aus cron_cssstyledimgtext
<pre>
<?php
if (!defined ('TYPO3_MODE')) die ('Access denied.');

t3lib_extMgm::addPItoST43($_EXTKEY,'pi1/class.tx_croncssstyledimgtext_pi1.php','_pi1','',1);

$_EXTCONF = unserialize($_EXTCONF);
if ($_EXTCONF['addPageTS']) {
t3lib_extMgm::addPageTSConfig('
TCEFORM.tt_content.imageorient.types.image.removeItems = 8,9,10,17,18,25,26
');
}

$TYPO3_CONF_VARS['FE']['XCLASS']['tslib/class.tslib_content.php']=t3lib_extMgm::extPath($_EXTKEY).'class.ux_tslib_content.php';
?>

</pre>

Htaccess

2006-07-06T08:59:55Z

84.161.146.115:

== Anwendung von .htaccess - Dateien ==
von: http://www.uni-duesseldorf.de/Service/Webmaster/htaccess.php3 Juli 2006

Referenz: Apache Manual: http://www.uni-duesseldorf.de/apache-manual/

=== Wozu braucht man das ?===
An wen ein HTTP-Server Dokumente herausgibt, welche spezielle Verarbeitung er u.U. bei einer spezifischen Anforderung (einem request) durchführt - all das wird zunächst durch eine von der Server-Software abhängigen Konfiguration bestimmt, die ein Administrator - ein Webmaster - eingerichtet hat.

Oft ist es aber wünschenswert, daß einzelne Verantwortliche für eine Dokumentenhierarchie auf dem Web-Server selbst ohne Intervention des Webmasters Setzungen vornehmen können, daß z.B. auf einzelne Dokumente oder alle in einem bestimmten Verzeichnis nur ein Zugriff aus bestimmten Domains oder mit verifiziertem Usernamen möglich ist.

Beim Apache-HTTP-Server wie seinem Vorgänger, dem NCSA-httpd, gibt es diese Möglichkeiten durch die Einrichtung von .htaccess-Dateien in dem jeweiligen Verzeichnis. In der folgenden Darstellung wird als Referenz jeweils ein Verweis auf den entsprechenden Abschnitt in der lokale Kopie der Apache-Dokumentation für die Version 1.2 gegeben.

'''Achtung:''' In der Server-Konfiguration kann ein anderer Name als .htaccess vereinbart sein (AccesFileName-Direkt ive).

'''Zweiter Hinweis:''' Die Datei muß für den HTTP-Server lesbar sein, z.B. dadurch erreicht, daß sie öffentlich lesbar ist:

chmod 644 .htaccess

=== Zugriffsbeschränkung auf eine Domain ===
==== für alle Dateien in einem Verzeichnis ====
'''.htaccess'''

order deny,allow
deny from all
allow from .uni-duesseldorf.de 134.99

Alle Dateien in dem Verzeichnis werden nur an Clients ausgeliefert, die eine IP-Adresse beginnend mit 134.99 oder einen Hostnamen endend mit uni-duesseldorf.de besitzen; anderenfalls erfolgt eine Fehlermeldung des Servers (403 Forbidden).

Natürlich genügt in vielen Fällen eine der Alternativen. Beachten Sie dabei die Unterschiede:

* Die Angabe des Domain-Namens allein schließt - bewußt oder nicht - den Zugriff von PC's aus, die nicht im Domain Name System (DNS) registriert sind.
* Die Angabe des IP-Subnetzes allein kann andere ausschließen, die organisatorisch zur gleichen Domain gehören, technisch aber in einem anderen Subnetz hängen.

Wie lässt sich diese Zugriffsbeschränkung testen? Normalerweise benötigt man dazu einen Internet-Zugang über einen anderen Provider (T-Online, AOL, Compuserve etc.). Oder man benutzt einen Browser auf dem Server selbst z.B. in folgender Weise:

lynx http://localhost/Service/Webmaster/htaccess.phtml

Der Zugriff erfolgt dann über das Loopback-Interface mit der IP-Adresse 127.0.0.1.

Referenz: order, deny, allow.

==== für einzelne Dateien ====
'''.htaccess'''

<Files huh*.html>
order deny,allow
deny from all
allow from .uni-duesseldorf.de 134.99
</Files>

Die Zugriffsbeschränkung wie oben gilt jetzt nur für die Dateien, deren Namen auf das hinter Files angegebene Muster passen. Es kann ein einzelner Name angegeben werden oder ein Muster mit den Wildcard-Zeichen ? für ein beliebiges einzelnes Zeichen oder * für eine beliebige Folge von Zeichen.

Schließlich sind auch feinere Muster über reguläre Ausdrücke möglich. Die Syntax der Files-Direktive dafür ist:

<Files ~ "regexp">

Referenz: <Files>, order, deny, allow.

=== Zugriffsbeschränkung über Passwort ===
==== für ein Verzeichnis ====
'''.htaccess'''

AuthType Basic
AuthName MeyersLeute
AuthUserFile /home/meyer/passwd
require valid-user

Dokumente in einem Verzeichnis mit dieser .htaccess-Datei (oder einem Unterverzeichnis) können erst nach Eingabe eines gültigen Benutzernamen und Passwortes gelesen werden. Der Wert hinter AuthName wird vom Browser in der Dialog-Box für die Passwortabfrage angezeigt und dient gleichzeitig dazu, andere Dokumente mit dem gleichen Schutz zu erkennen und einmal eingelesene Werte für Username und Password ohne erneute Abfrage unmittelbar zu verwenden.

Hinter AuthUserFile steht der Pfad der Passwortdatei, die die Benutzernamen und (verschlüsselten) Passwörter enthält. Sie sieht etwa so aus:

/home/meyer/passwd

meyer:xm.kPd4VJc3Fo
mueller:eJFQCL8GftDXI

Auch die Passwortdatei muß für den HTTP-Server lesbar sein. Gerade deshalb sollte sie niemals in demselben Bereich liegen wie die vom Server bedienten Dokumente, da sonst zumindest die gültigen Benutzernamen lesbar wären. (Aus diesem Grund müssen Sie aber u.U. daran denken, auch das entsprechende Verzeichnis - wie /home/meyer im Beispiel - für den HTTP-Server zumindest suchbar zu setzen, also etwa:

chmod 711 /home/meyer

Angelegt und gepflegt werden kann die Passwortdatei mit dem Programm htpasswd:

htpasswd -c /home/meyer/passwd meyer
htpasswd /home/meyer/passwd mueller

Referenz: AuthType, AuthName, AuthUserFile, require.

==== für einzelne Dateien ====
'''.htaccess'''

AuthType Basic
AuthName MeyersLeute
AuthUserFile /home/meyer/passwd
<Files Huh*.html>
require user meyer mueller
</Files>

Die Kombination von 2. und 3. - Passwortschutz für einzelne Dateien in dem aktuellen Verzeichnis. Beim require wird hier noch eine andere Alternative gezeigt: die Aufzählung einzelner Benutzernamen aus der Passwortdatei. Wenn neue Benutzer in der Passwortdatei ergänzt werden, haben diese noch keinen Zugriff auf die so geschützten Seiten.

Wenn die gleiche Liste von Benutzern an mehreren Stellen verwendet werden soll, ist die Definition der Liste über eine Gruppendatei empfehlenswert. Für diese dritte Alternative bzgl. der require-Direktive sind fogende Änderungen notwendig:

1. In der .htaccess-Datei wird eine Gruppendatei angegeben:
AuthGrouprFile /home/meyer/groups
Für den Ort der Ablage dieser Datei gelten dieselben Erwägungen wie für die Passwortdatei oben.
2. In der require-Direktive wird jetzt auf eine Gruppendefinition in der Gruppendatei Bezug genommen:
require group meyers
3. Die Gruppendatei ist eine einfache Textdatei mit je einer Gruppendefinition pro Zeile in folgender Form:

/home/meyer/groups
meyers: meyer mueller

Referenz: AuthType, AuthName, AuthUserFile, AuthGroupFile, <Files>, require.

===Spezielle Optionen===
==== automatischer Index (Directory Listing)====
'''.htaccess'''
Options +Indexes

Mittels der Options-Direktive können - so von der globalen Server-Konfiguration her erlaubt - Voreinstellungen für Verarbeitungsoptionen für das aktuelle Verzeichnis und Unterverzeichnisse überschrieben werden.

Die gezeigte Variante weist den Server an, bei der Referenz auf das aktuelle Verzeichnis oder ein Unterverzeichnis ein Directory-Listing als Index-Datei automatisch zu generieren. Er macht dies allerdings nur, wenn nicht schon eine Index-Datei (mit vordefiniertem Namen wie index.html) vorhanden ist. Ggf. kann man die hier bekannten Namen mit der Direktive

DirectoryIndex Welcome.html

einschränken.

Referenz: Options, DirectoryIndex.