One of those alternative options include having a selector box shown in a third frame in the "top-bar". That frame will have the JavaScript reference "top.menu" in substitute for the left menu and is made by the script "alt_menu_sel.php".

So setting the user profile like this...

... will yield this result for backend menu navigation:

You can also have the menu as a list of icons in the top frame. This obviously requires you to know the menu items by heart so you can recognize the items on their icons only without the descriptive labels:

... and the menu will look like:

Basically there are two types of modules, main modules and sub modules. Normally we refer to them just as "modules" or "backend modules".

The term "modules" is used within TYPO3 specifically for these backend modules. For the frontend we might also like to call a message board or guest book for "a module". However to distinguish between the two worlds we use another term, "plugins", for frontend applications such as message boards, shops, guest books etc.

Modules are discussed in detail later in this document. For now just observe the distinction between main- and submodules:

Main modules are those on the "first level" in the menu. Most of them are not linking directly to any script but are merely "headlines" for the submodules under them. One exception is the "Doc" module which is linked to the alt_doc.php script.

Sub modules are those on the second level in the menu. As such they don't have to have any technical relationship with the main module. The main module might simply act as a category for the module. However for "Frameset modules" it's a little different (see next section). Sub-modules may be named "Web>List" or "User>Setup" but we encourage unambiguous naming of modules so any module can be referred to by its own name only, eg. "List module" (Web>List) or "Filelist module" (File>Filelist) - it turns out to be much easier to say in words "The filelist module" than "The File-Filelist module".

Finally "Function menus" are what you get when you create backend modules "on the third level" - basically a module which inserts itself into a menu of an existing main- or sub-module. This of course requires the host module to supply an API for that, but that is in fact the case with both the "Info" and "Functions" modules!

In this example the extension "info_pagetsconfig" has been loaded in the EM (Extension Manager) and thus the Info module will show this item in the menu:

Main modules can be configured to load a frameset into the content frame instead of the modules default script. This is the case of the Web and File main modules. In itself that might sound trivial but the point is that "Frameset modules" are more than just a "category" for submodules - they are offering additional features:

In the case of frameset modules the idea becomes clear when you observe the usage; Both the Web and File main modules offers a two-split window with a page/folder tree on the left and a sub-module script loaded in the right frame. The point is that a click in the left frame will load the sub-module script in the right frame with an &id= parameter! In the case of the Web module this "id" is of course the page id, for the File module it's the path to the directory that should be shown.

Still this could be achieved by a local frameset made by the module itself, but the main point is that even if you switch between the sub-modules in the menu the id-value is passed along to the other sub-module and further will the id be restored and sent to the script when a totally other module has been accessed in the meantime and the user goes back to one of the sub-modules within the frameset module.

For instance you might click the page "A page title" below, the List module will show the records for that page id, then you go the the Extension Manager and when you later click on the List, Info, Access or Functions sub-module the last page id displayed will be shown again.

That is what a Frameset module does.

(See the module section for details on how to configure such a module)

A Frameset Module consists of these scripts:

Certain requirements are put on the function of the navigation and sub-module scripts in order to ensure complete compatibility with the concept of Frameset Modules. This is basically about updating some JavaScript variables in the main frameset. See the module section for more details.

If Condensed Mode is enabled for the user it has an impact on how Frameset Modules handles the splitting of the screen into navigation and list frame. Basically the frameset is not used and the communication goes always from menu -> navigation frame -> list frame:

This mode is designed to help people with small screen resolutions to keep all the information on the screen without having to scroll horizontally (too much). In default mode TYPO3 runs best at resolutions of 1024x768 or above.

Each script in the backend is required to include the init.php file. For core scripts this is done as the first code line in the script:

require ('init.php');

An example could be the alt_main.php script (the backend frameset):

/** * Main frameset of the TYPO3 backend* * @author    Kasper Skårhøj <kasper@typo3.com>* Revised for TYPO3 3.6 2/2003 by Kasper Skårhøj*/require ('init.php');require ('template.php');require_once (PATH_t3lib.'class.t3lib_loadmodules.php');require_once (PATH_t3lib.'class.t3lib_basicfilefunc.php');require_once ('class.alt_menu_functions.inc');// ***************************// Script Class// ***************************class SC_alt_main {    var $content;    var $mainJScode;    var $loadModules;    var $alt_menuObj;

These are comments on the various parts of the above source code:

For modules (located elsewhere than in the TYPO3_mainDir) the following initialization must be done prior to inclusion of init.php:

An example is seen in the install/index.php file:

define('TYPO3_MOD_PATH', 'install/');

$BACK_PATH='../';

require ($BACK_PATH.'init.php');

If a script is positioned outside of the TYPO3_mainDir it must be in the typo3conf/ directory. In that case the initial lines could look like this:

define('TYPO3_MOD_PATH', '../typo3conf/my_backend_script/');

$BACK_PATH='../../typo3/';

require ($BACK_PATH.'init.php');

Modules

Modules will typically initiate with basic lines like these:

unset($MCONF);

require ('conf.php');

require ($BACK_PATH.'init.php');

So before init.php is called the local "conf.php" file is included. That file must define the TYPO3_MOD_PATH constant and $BACK_PATH global variable. The modules section will describe this in detail.

We could take mod/web/perms/index.php as an example. Here the conf.php file looks like this:

<?phpdefine('TYPO3_MOD_PATH', 'mod/web/perm/');$BACK_PATH='../../../';//... (additional configuration of module)...

?>

Modules in typo3conf/

Another example is from a conf.php file of a locally installed extension (such are located in the "typo3conf/ext/" directory) with a backend module:

<?php    // DO NOT REMOVE OR CHANGE THESE 3 LINES:define('TYPO3_MOD_PATH', '../typo3conf/ext/charsettool/mod1/');$BACK_PATH='../../../../typo3/';

//... (additional configuration of module)...

?>

So what happens in init.php?

The short version is this:

The verbose version is this:

(All global variables and constants referred to here are described in "TYPO3 Core API")

So that is what happens in init.php!

This is the classes already included after having included "init.php":

Possibly other classes could have been included in "ext_tables.php" files or "ext_localconf.php" files. This is OK for the "localconf.php" file, but not necessarily for extensions. Please see the Extension API description for guidelines on this.

A short notice on system variables:

Don't use any system-global vars, except these:

HTTP_GET_VARS, HTTP_POST_VARS, HTTP_COOKIE_VARS

Any other variables may not be accessible if php.ini-optimized is used!

Environment / Server variables are also very critical! Since different servers and platforms offer different values in the environment and server variables, TYPO3 features an abstraction function you should always use if you need to get the REQUEST_URI, HTTP_HOST or something like that. At least never use the PHP function "getenv()" or take the values directly from HTTP_SERVER_VARS - rather call t3lib_div::getIndpEnv("name_of_sys_variable") to get the value (if it is supported by that function). You can rely on that function will deliver a consistent value independently of the server OS and webserver software.

You should refer to the TYPO3 Coding Guidelines or TYPO3 Core API for more information about this or go directly to the source of class.t3lib_div.php.

There is a host of methods inside the template class which can be used. Some of these are documented in "TYPO3 Core API" and others by examples in various Extension Programming Tutorials.