De:Install-Tool 2.0

From TYPO3Wiki

Install-Tool 2.0

Translations info An english page for every translation. All pagenames in english.   en       de   nl   fr   ja   zh

Contents 1 Übersicht 1.1 Ideen 1.1.1 Wilkommensbildschirm 1.1.2 Neuinstallation 1.1.3 Neue Seite erstellen 1.1.4 Konfigurations-Einstellungen 1.1.5 Update 2 Konzept 2.1 Wie die Module arbeiten 2.1.1 Verzeichnisstrukturen und Dateinamen 2.1.2 the module class 2.1.2.1 main 2.2 Render Objects 3 Open questions 3.1 Do we want to keep t3lib_install? 3.2 Which modules we want to have? 3.3 Security 3.4 Existing examples 4 Current Project Members 5 Wishlist

Übersicht

Das momentane Installationswerkzeug ist eine große Konstruktion, die es ermöglicht die grundlegenden Einstellungen für eine Typo3-Installation zu treffen. Außerdem installiert und überprüft es die Datenbank anhand einer SQL-Datei. Desweiteren überprüft es Dinge wie Verzeichnisse und ImageMagic-Einstellungen.

Wie eingangs genannt besteht es zur Zeit aus einem einzigen, großen PHP-Script. Aus diesem Grund kann man es nur schwer warten. Auch die Ausgabe (besonders bei "All settings") ist sehr umfangreich und dadurch recht unübersichtlich.

Das Install-Tool 2.0 Projekt hat das Ziel das Installationswerkzeug umzuschreiben und den Code in Module aufzuteilen, die leichter gewartet werden können. Ein weiterer Grund für eine solche Umgestaltung ist, das Installationswerkzeug durch Extensions erweiterbar zu machen. Das könnte für Benutzer von RealURL oder DBAL recht nützlich werden.

Ideen

Viele Ideen wurden gesammelt wie man das Installationswerkzeug verbessern kann. Sie wurden in der HCI Mailingliste diskutiert. Jens Hoffmann und Patrick Gaumond haben diese Ideen zusammengefasst.

Wilkommensbildschirm

• 3 Links: 'Update', 'Neuinstallation', 'Erfahrener Benutzer' (ohne Assistenten)?
  • eine Seite, die upgedated wird, soll automatisch erkannt werden
  • 'Erfahrener Benutzer' leitet direkt weiter zu 'Alles Konfigurieren'
  • Nicht verwendete Buttons kann man nicht anklicken (Deaktiviert)
  • Ansprechende graphische Begrüßung, warm...
  • vielleicht 'Auf neue Version überprüfen'

Neuinstallation

• Verpflichtete Schritte
  • "Schritt 0": Der Benutzer muss nur das Installationsscript uploaden. Bei Schritt 0 bezieht es dann die restlichen Daten von allein.
  • Vor-Installations Überprüfung (BENÖTIGT / nötige Einstellungen)
    • Berechtigungen für Dateien / Ordner
    • php.ini Einstellungen ('basic configuration' beim jetzigen Installationswerkzeug)
      • Verzeichnis bei include path
      • Memory Limit
      • Max Execution Time
      • Functions disabled: none
      • MySQL Funktionen verfügbar
        • vielleicht auch andere Datenbanken???? (DBAL)
      • Datei Uploads aktiviert
    • Wenn die Einstellungen nicht korrekt sind, kann man zwar weitermachen, aber es erscheint eine große Warnung und eine Javascript Bestätigung wenn man auf 'next' klickt.
    • Ein 're-check' Button um die fehlenden Einstellungen zu überprüfen
    • Hilfreiche Informationen: Pfad zur php.ini
• Datenbank
  • als Standard: MySQL (vielleicht auch andere DB Typen??) / zumindest eine Notiz dafür hinzufügen
  • Hostnamen eingeben (Standardwert: 'localhost') und DB Username und Passwort
  • Datenbank erstellen oder eine bestehende DB wählen (so wie jetzt)
    • wenn die existierende DB bereits Tabellen hat -> Warnung / weitere Überprüfungen
• Admin User hunzufügen
• Install-Tool Passwort setzen
  • 'Encryption Key' automatisch auf eine Zufallszahl setzen
• 'Zwischenseite' - 'Du hast es fast geschafft...'
• Empfohlene Schritte (wenn es einen Fehler gibt - überspringen oder erneut prüfen)
  • PHP Überprüfungen (ausführlich)
    • Ist nicht verpflichtend, wäre aber nett
    • Safe Mode
    • Max Upload Filesize
    • zlib
    • open_basedir
• Zeichensatz Einstellungen (UTF-8 wird empfohlen und wird Standardeinstellung sein) (Die Auswahl muss vor Erstellung der Datenbanktabellen und deren Inhalt geschehen)
  • [t3lib_cs_utils] müssen zugewiesen werden wenn externe Libs verfügbar sind
• Graphische Einstellungen
  • Automatische Erkennung und manuelle Einstellung des Suchpfades
    • GM wird bevorzugt
  • Beispielbilder, etc
  • die 'Bilder Demos' sollten Typo3 Funktionen verwenden!!
• Mail Einstellungen
  • zuerst Erkennung
  • E-Mail testen
• Datum und Uhrzeit Einstellungen
  • Server Zeitzone
  • Notiz: verschiedene BE Sprachen im Extension Manager verfügbar
  • (vielleicht) CURL Erkennung und Einstellungen
  • bei deaktivierten url fopen Wrappern
• Automatische Erkennung (User über die Einstellungen informieren + Begründung)

Neue Seite erstellen

• Seitenname
• Templates importieren
  • ein Template muss bereitgestellt werden, damit eine offline-Installation funktionieren kann
  • Dummy Inhalt
  • Was ist mit Extensions? (+1 um Extensions auf diesem Level zu installieren. 10 auswählen und das Tool installiert sie)
• Sicherheit (Installations-Tool deaktivieren)
• Gratulations-Seite
  • Zum BE/FE/Konfiguration

Konfigurations-Einstellungen

• 'Einfacher Modus' / Auto-Erkennungs Modus
  • Bietet Automatische Erkennung und alles was im 1.2.3 Assistenten vorgekommen ist
  • Wie der Assistent, nur ohne 'voreingestellten Pfad'
  • dass man jede 'Sektion' alleine ausführen kann
  • Hauptnavigation:
    • Graphik
    • E-Mail
    • Datum/Zeit
    • CURL
    • Neue Seite basierend auf Template
    • Seitenname
• 'Fortgeschrittener Modus' / Manueller Modus
  • keine Automatische Erkennung
  • _alles_ einzustellen
  • (so ziemlich wie 'all configuration' jetzt)
  • Einstellungen updatens??

Update

• DB Vergleich
• Upgrade Assistent
  • die nicht abwärtskompatiblen Änderungen durchführen (z.B: MD5 FE User Passwörter)
  • Kompatibilitätsversion einstellen (benötigt händische Einstellungen)
  • vielleicht... Extension Kompatibilitätsüberprüfung (basierend auf ext_emconf.php - Wert)

Konzept

Die Basis-Idee des Install-Tools ist es, es in mehrere Module aufzusplitten, so dass diese an verschiedenen Stellen des Install-Tools aufgerufen werden könnnen. Ein weitere wichtiger Punkt dabei ist, dass einzelne Module keinen HTML-Code zurück liefern sondern Meta-Informationen, so dass diese durch die "View-Class" des Install-Tools zur Anzeige gebracht werden. Dies hat mehrere Vorteile. Als erstes müssen die Module nicht wissen, wie der Output später aussehen soll oder welche Code-Guidelines eingehalten werden müssen. Der Output wird immer so aussehen, wie der Rest von TYPO3. Außerdem können die einzelnen Module auch aus anderen Modulen heraus aufgerufen werden. Zum Beispiel kann das "Preinstall"-Modul das "PHP-Check"-Modul, das "Verzeichnis-Check"-Modul, das "DB-Check"-Modul u.s.w. aufrufen.

Wie die Module arbeiten

Dies ist das erste Konzept, wie Module im Install-Tool 2.0 arbeiten. Dieses Dokument ist ständig in Bearbeitung, bis es als "freezed" markiert wird. So lange kann der Inhalt sich ohne Ankündigung ändern.

Verzeichnisstrukturen und Dateinamen

Alle Module werden im Verzeichnis "modules" innerhalb des Extension-Verzeichnisses liegen. Jedes Modul hat sein eigenes Verzeichnis, welches dem Namen des Moduls entspricht. Dieser Name muss eindeutig sein. Innerhalb des Modul-Verzeichnisses gibt es mindesten eine PHP-Datei welche den Namenskonventionen von TYPO3 entspricht. Der Name beinhaltet "class.tx_install_module_" gefolgt von dem Modulnamen. Die Datei enthält genau eine Klasse mit dem gleichen Namen wie der Dateiname, aber ohne "class", "php" oder jeglichen Punkten ("."). Daraus ergibt sich die folgende Verzeichnis-Struktur:

install
 \- modules
     \- php
     |   \- class.tx_install_module_php.php
     \- database
     |   \- class.tx_install_module_database.php
     \- etc.

Alle andeeren Dateien, welche vom Modul benötigt werden, finden sich innerhalb des Modul-Verzeichnisses wieder. Dabei ist es egal, ob die Dateien in Unterverzeichnissen liegen oder direkt im Modul-Verzeichnis.

the module class

This section describes how a module class (object) has to look like. It explains the needed methods that are defined by the API for the installer. Aditionally to the necesarry methods, you can define as much methods as you want as long as they have no presetted names.

main

A module has to contain a main method. This method is called whenever the module is called by the dispatcher. This method will receive the complete command array that was originally passed to the Install-Tool. No matter if the params came from the URL, session or somwhere else. The second parameter will be an array that concludes all results that where already collected when the modules is called. This array will be an array that contains plain data without any information about formation. The third parameter is the installer object the module was called from. This object contains various status variables and all helper objects (for example the basics object) The return value of the main method has to be an resultset that contains the output stream that can be parsed by the view class and a set of plain results that is stored in the module-result storage. This stream format has to be described. An example implementation could look like this:

function main($args, $currentResults, $pObj)	{
	// do the magic...
}

Render Objects

The output of a single module has to be done by the install-tool and *NOT* by the module itself to make sure, that the output is always the same, even for different modules. To achieve this, the modules return a result object that contains the collected results. These result consists of plain information about how many checks has been performed and how many of them have a positive result and how many not. Additionally it contains all output data of the module. These output data are plain messages, lists of results and stuff like that.

The result-set is passed to the render methods in the view-object of the installer. Within the render-process the single result-sets from the modules will be passed to special render-methods. This combination of result-set and render-method is called render-object. The principle behind that is, that a result-set can contain other complete result-sets in itself. In the render process, there will be created new render-objects for this result-set. So it is possible to have nested result outputs.

The render-objects are:

• plain - Renders the input-stream as it comes in
• list - Expects a list of input-streams and renders them as unordered list
• message - The input-stream defines a severity beside the message
• ... more to come ...

Open questions

Things that have to be checked for Install-Tool 2.0

Do we want to keep t3lib_install?

This class provides several methods for checking the database and writing and reading stuff from the localconf.php file.

• Thomas: Personally I would really like to see this stuff in the database module and the tx_install_basics. I'm not sure if this can be solved. The second best solution would be to alter the core files and improve the code.
• Sebastian: I would as well move it to the DB and tx_install_basics module and adjust the core for that!

Which modules we want to have?

Currently I have created some diretcories for the basic modules we all agreed that we need them

• install - resembles the current "1-2-3" installer
• overview - dashboard
• update - update module
• compatibility settings - resembles the current "update wizard"
• php
• database
• directories
• statistics
• graphics
• create admin user - simple module, but makes sense nevertheless
• uninstall extensions - security related, see below

All the above modules are needed for the first release, as they all resemble already existing functionality of the install tool.

Security

By making the Install-Tool extendable it might be possible that an extension introduce some evil code. Is this a serious danger?

• I think the dashboard should not be extendable meaning it should run under all circumstances. Then, we need one module to remove extensions which cannot be modified in any way. --kurfuerst 17:30, 27 November 2006 (CET)

• Since Install Tool is a sysext anyway, maybe it should not be extendable by normal extensions, thus ensuring a secure, well tested installation tool. -- Patrick

Existing examples

The WEC guys are working on a tool similar to the install tool that checks the server environment to make sure everything needed for TYPO3 is there. The design is very modular, with single modules as tests, a module controller that manages all the modules and their results, and a render controller with different renderers that process the results from the module controller and display them in various ways. SVN is available at http://svn.webempoweredchurch.org/wec_servercheck/

There's also this new extension: security_check
http://typo3.org/extensions/repository/view/security_check/0.1.2/

Current Project Members

Thomas Hempel <thomas(at)typo3-unleashed(dot)net>

Wishlist

Extension mangement part of the install process.