All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Install-Tool 2.0

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Install-Tool 2.0 project (category Project)

This project is currently on hold.

However, there have already been many of the improvements planned here - check out TYPO3 4.4...


The existing Install-Tool is a huge construct for setting most of the basic settings to run TYPO3 (see installation). It also installs and checks the database based on a provided SQL file. Furthermore it checks some things like directories and ImageMagick settings. As mentioned before, the current implementation is a single huge PHP script. This is not very good to maintain. Also the output (especially the "all settings") is very large and not good to use. The Install-Tool 2.0 project has the goal to rewrite the Install-Tool and split up the code into various modules that can be maintained easier. Another issue is, to make the Install-Tool extendable through extensions. That can be useful for example for DBAL and RealURL.


The project is currently stopped! Here is a short status report.

The basic stuff in the framework is ready for use. What Is actually missing is some interface. The project currently uses extJS for drawing a category tree and some forms. Some things like input fields (for various types) have to be implemented. It's also needed to re-build the functionality to execute methods from certain modules. This was already implemented but has to be ported to the new extJS interface.

The database module needs some update. For this module, the original code came from the original installer. Since that day, a lot of changes were made to the original code. Changes that were not ported to the new code-base. The image module is almost done but also need some polish. All other modules are not that difficult. All options that are available in the current default config have to be ported to the new installer structure (modulename/conf.php).

The biggest part is the installer itself. Formally know as 1-2-3 installer, the module "installer" is not much more than a skeleton yet. It works basically but a lot of things, like pagination, proper data handling, skinning, modularity, are not selved very elegant yet. This module has to be rewritten from scratch.

For questions you can contact me at Please contact me only if it is really needed because I stopped this project for myself du to personal reasons.


One of the great changes is not about programming but usability in some way. We'll change the naming of the Install-Tool. The following will change:

  1-2-3 Installer => Installer
  Installer Module => Setup 
Ideas for Install-Tool navigation in advanced mode


A lot of ideas had been collected how the Install-Tool can be improved. The points were discussed in the HCI mailinglist. Jens Hoffmann and Patrick Gaumond have collected all these ideas.


This is the roadmap that is designated to be the master plan for Installer 2.0 development. This roadmap is not the bible. If things go faster or take longer this roadmap will be updated. It's just a rought schedule!

  • 11.06.2007
    • Start survey to get final input from the community
  • 06.07.2007
    • Close survey and analyze results
  • 11.07.2007
    • Publish results from survey [1]
    • Start re-implementation
  • 31.07.2007 - Milestone 1
    • Working framework with all needed components for final feature-plan
    • Start of module re-implementation
  • 20.09.2007 (T3CON07) - Alpha1
    • Publishing a first Alpha version that can be used for testing.
    • Start of beautifying the interface
  • 31.10.2007 - Alpha2
    • Second Alpha version with working interface (Not necessarily everything is implemented)
  • 30.11.2007 - Beta1 / Feature Freeze
    • First beta with everything implemented
    • Feature Freeze
    • Start of testing by community
    • From this point new releases will come daily if necessary!
  • 01.01.2008 - RC1 (Rebirth)
    • Release Candidate Number 1
  • 07.01.2008 - Integration
    • Integration into the TYPO3 Core
    • Big party! ;-)

Feature plan

This plan is constructed from the research that where made in the past. It also bases on the results form a survey that where made in June 2007.

This part is still under development!!!

  • New interface
    • Complete outstanding look for installation
    • using of skin in backend
    • rename current module "Install" to "Setup"
  • Command Line Interface
    • Make important tasks available via a CLI
  • Modularization
    • All Setup-Modules are encapsulated within independet modules.
  • New rendering
    • Installation: Basic PHP-HTML "Templates"
    • Setup: Using TYPO3 rendering options or own basic rendering engine
  • Multilinguality
  • All-time cancellation (Cancel Installation at any time after mandatory steps 1 to 3)
  • Support for DBAL
  • Net-Install
  • Organizing structure as tree
    • Catgories
    • Tagging of options

Interface screens

These screens are still proof of concepts and will not necesarrily implemetend in final version.

Welcome Screen

Wizard - Help-Box at the Right
Wizard - Help-Box at the Bottom
Wizard - No Help-Box
  • 3 Links: 'update', 'new install', 'advanced users' (no wizard)?
    • an updated site should be auto-detected
    • 'advanced users' links directly to 'all configuration'
    • Not used buttons are not clickable (greyed out)
    • Graphical welcome image, warm, ...
    • maybe 'Check for new version'

New Install

Wizard - Deeper Step
Wizard - Final Step
Configuration Manger insight of the Backend
First draft of the Install-Tool 2.0 framework
  • Mandatory steps
    • "Step 0": Users have to option to only upload the Installer Script. In Step 0 this Script fetches the rest of the needed files from the server by itself.
    • Pre Install check (NEEDED / mandatory settings)
      • Permissions for directorys / files
      • PHP Ini Settings (php.ini, look to 'basic configuration' of current install tool)
        • Current dir in include path
        • Memory Limit
        • Max Execution Time
        • Functions disabled: none
        • MySQL Functions Available
          • maybe other DBs as well???? (would be good to choose ADOdb directly or via DBAL)
        • File Uploads enabled
      • If settings are not fullfilled, you can still continue, but there will be a big warning and an additional javascript confirmation when clicking 'next'
      • We want a re-check button to let people change the missing settings
      • Helpful information: Path to php.ini
  • Database
    • by default: MySQL (maybe other DB types, too??) / at least add a note for that
    • enter hostname (prefilled with 'localhost') and DB username and password
    • Create new DB or select existing one (like it is now)
      • if the existing DB has tables inside -> warning / deeper checks
  • Add Admin User
  • Set Install Tool Password
    • set encryption key automatically to a random value
  • 'Link page' - 'You are halfway done...'
  • Recommended steps (if there is an error, open the possibility to skip or recheck the step)
    • PHP checks (deeper)
      • what is not mandatory but nice
      • Safe Mode
      • Max Upload File Size
      • zlib
      • open_basedir
      • max execution time (since many webhosters have limited execution time)
  • Character set settings (we recommend UTF-8 and this will be the default one) (The choice must be made before the database tables are created and data is inserted) (an idea is to use utf-16 as alternative default --Daniel Brüßler 19:08, 6 January 2007 (CET))
    • [t3lib_cs_utils] needs to be set if external libs are available
  • Graphics settings
    • Autodetection and manual setting of search path
      • we prefer GM (see ImageMagick - GM is inside the list)
    • Example images, etc
    • the 'image demos' should use TYPO3 functions!!
  • Mail settings
    • detection first
    • test email
  • Date and Time settings
    • including server timezone
    • Note: different BE language available in extension manager
    • (maybe) CURL detection and settings
    • if url fopen wrappers are disabled
  • Autodetection (inform the user of the settings we set, and why)

maybe interesting tags: symbolic links, performance, accelerator, SSL, Linux, Windows, Image Processing --Daniel Brüßler 19:32, 6 January 2007 (CET)

Create new site

  • Sitename
  • Import Templates
    • we have to provide one template, to make an offline installation work
    • Dummy Content
    • What about extensions? (+1 for installing extension on this level in bulk. Select 10 and the tool installs them)
  • Security (disable install tool)
  • Congratulation Screen
    • Go to BE/FE/Configuration

configuration settings

  • 'simple mode' / autodetection mode
    • provides autodetection and everything which was set from the 1.2.3 wizard
    • it is like the wizard without the 'predefined path'
    • so you can run every 'section' on its own
    • main navigation:
      • Graphics
      • Mail
      • Date/Time
      • CURL
      • New site based on template
      • site name
  • 'advanced mode' / manual mode
    • no autodetection
    • set _everything_
    • (pretty much like 'all configuration' today)
    • update settings??


  • DB compare
  • Upgrade wizard
    • do the non-backwards compatible changes (f.e. MD5 FE user Passwords)
    • Set compatibility version (requires manual adjustments)
    • maybe... Extension compatibility check (based on ext_emconf.php value)

Categorisation of options

An attempt to categorize all options that are present in the current installer was made, and the (preliminary) results are available: Install-Tool_2.0/Categories_for_Options. If you think an option fits better in another category, feel free to edit it. Also some options were put into more than one category - this is where we couldn't decide which fits best ;)


The basic idea for the Install Tool is to split it up into several modules that can be called on different places inside the Install-Tool. Also an important thing is, that the single modules should not return any HTML code but some sort of meta-output that is rendered by the view class of the Install-Tool. This has several advantages. First, the modules don't have to care about the skin or any HTML guidelines. They will always look like the rest of TYPO3. And the single modules can be called from within other modules. For example the preinstall-module can call the PHP-check module, the directory checks, DB checks and so on.

How modules can work

This is a first draft of the concept on how modules in the Install-Tool 2.0 can work. This document is in progress until it's marked as freezed. Until that, the content can be changed anytime without any warning.

Directory structure and filenames

All modules are placed in the "modules" directory inside the extension directory. Every module has it's own directory with the name of the module. This name has to be unique. Inside the module directories there has to be at least one php file that fits the naming conventions of TYPO3. The name contains "class.tx_install_module_" followed by the modulename. The file contains exactly one class named same as the filename without "class", "php" or any dots. This leads to the following example structure:

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

All other files that are needed by the modules have to be placed inside the module-directory. Therefor it doesn't matter if the files are located in various sub directories or if they are placed directly in the module directory.

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.


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 LocalConfiguration.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.


(see 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

There's also this new extension: security_check

Current Project Members


Extension mangement part of the install process.
RealURL install/configuration as part of install process.

Bugs that I encountered with the old version that I do not like to see in Install Tool 2.0

  •  : This happened to me just today: I used the install tool to create a new TYPO3 installation (1-2-3). Step three was importing the data to the DB and the next screen was empty. The DB import failed. It appeared to me that in my php configuration the memory limit was set to 8 MB (default with RHEL), but that is what I read from the http error log files. It would be great if the memory limit would be checked BEFORE making this step available. But I'm sure you've already thought about something like that. ;-) - Benjamin Mack 12:00, 28 March 2007 (MESZ)
  • Not really a bug, but a usability glitch to me: If there is only a limited set of possible options, the user should not be able to enter a value in a textbox, but instead a selectbox with the options should be made available. Examples: explicitADmode, im_v5effects and some others. It should also be possible to display a list with all items and their description after the list. -- Andreas Wolf 22:47, 10 September 2007 (CEST)


The reimplementation of the Installer for TYPO3 is a pretty huge project. We already invested lots of time and we didn't started any implementation work yet. We expect that we need to invest a lot more hours to complete the first version for 4.2.

As a matter of fact, TYPO3 is an Open Source project and we will do the work for our personal fun and to satisfy our personal needs. A lot of reason drives us to do what we do. Anyway, it would be nice get payed for the work even if this is not requirement. If you or your company want to support us, it would be nice if you contact us at installer2(at)typo3-unleashed(dot)net and we can talk about sponsoring.

Thank you in advance!