Several extensions will install AWStats into your site, and make the output available to Admins only, or other back-end users. You can also use Google Analytics, and various other tools, by adding the appropriate extensions.

Yes, though they may take their time about finding you.

There are two types of page content you DON?T want to have indexed: pages such as monthly and yearly calendar displays which have hundreds of links to very similar or identical pages, and restricted content.

You can stop this from happening by adding the appropriate instructions through page extension templates

Search engines will not, by default, see any content which cannot be accessed through links which are unrestricted.

You should also be aware that some extensions use AJAX to fetch content dynamically, and this may not be seen by search engines; the extension's manual should make this clear (you do RTFM, don't you?).

We can include an extension which generates a Google site map, and this should support Google (and other engines) in indexing what you do want them to index.

The Direct Mail Extension is an advanced Direct Mail/Newsletter mailer system with sophisticated options for personalization of emails including response statistics.

Each newsletter is created as a hidden page on the site, so you can include site contents in the newsletter if you wish.

You can categorise newsletters, and users can choose which of your newsletters they receive during the site registration process.

Additional modules allow people to register with the site, giving them the option to subscribe and unsubscribe to particular newsletters through their user profiles.

The usual site registration process requires the user to respond to an email before they can register, ensuring that they actually are interested, and have given you a genuine email address.

You can also import email addresses into the system if you wish.

If your major interest is in a shop, it may be better to consider basing your site on one of the many dedicated ecommerce solutions such as osCommerce.

However, TYPO3 has at least two sophisticated and highly configurable ecommerce solutions, tt_products, and commerce. Both have the advantage that they work within your main website, and give you more freedom of design (as well as consistency of design). Both of these are rare in dedicated solutions, which tend to generate web sites which are very similar to one another, unless you are adept at PHP programming.

Both solutions can be interfaced with payment gateways: it is best to use these, since they manage the security for you, and you do not end up with the task of protecting important data such as lists of credit card numbers yourself.

ecommerce solutions are basically designed to sell things, and they are much less good at dealing with repeating payments such as subscriptions. An extension is under development which automatically emails invoices to customers at the appropriate intervals.

TYPO3 is one of the few CMSs which is available as part of a setup programme which installs itself, plus a LAMP environment onto your hard disk, for local use.

The installation includes the Quickstart package, which is associated with a tutorial which covers all the basics of working with a TYPO3 website.

In addition, the TYPO3 site has a large range of video tutorials, which cover many basic (and some not-so-basic) issues in editing a web site.

TYPO3 is an enterprise level CMS which can deal with very large sites (including the TYPO3 site itself ? www.typo3.org)

It is inherent to the system that a site can be extended by adding new pages and new functions (by adding extensions). There is an extensive API and typoscript to assist you in developing your own extensions.

All of TYPO3's code can be modified if you need to do this, including that of extensions.

Issues common to very large sites, such as load balancing and the use of multiple servers are all possible for a TYPO3 installation, though in practice they require input from skilled professionals.

Everything on the site, including the templates and setup files as well as the variable page material is actually content. So not ALL site content is so easily updated.

However, anyone who can manage a WYSYWYG text editor similar to MS Word, and fill in forms should be able to update the variable page material, add and move pages, etc.

The granular back-end editing permission system makes it possible to make the interface more or less complicated, depending on the skills of the editor, and the taks they need to perform.

Users have a choice of selecting areas to update either through the back-end interface, which is generally not immediately WYSIWYG, or by selecting elements to update/add through the preview interface (which is completely WYSIWYG, apart from adding interfaces to allow selection of the content elements to update.

Front-end users can contribute or edit content either in the case of extensions such as forums or commenting systems, which are designed to support this, or, having logged in, to some other extensions such as news or calendar through a dedicated front-end interface, which keepes them altogether clear of the

The extent to which a TYPO3 site meets accessibility requirements depends largely on the discipline and skills applied to the site content throughout the development process. It is just as possible to get TYPO3 to generate an accessible site, as to get it to generate an inaccessible one.

Designs based on YAML start out significantly supporting accessibility features, bng based on semantic principles, and avoiding the use of tables as design elements. In addition, we normally consider issues such as what the site might look like to people with various visual impairments.

Other issues, such as giving images alt attributes, are supported by the system, but under the control of the editor.

In our experience, TYPO3 is as user-friendly as is consistent with the complexity of some of what it does. A complex on-line application is always going to require a fairly complex interface.

Setting up a system initially can be challenging, despite the existence of large amounts of documentation, and this is largely what has left TYPO3 with a reputation for being difficult. In order to allow flexibility, TYPO3 is complex.

Properly set up (with a separation of Admin and Editorial functions), TYPO3 can be very easy to work with: most editing can be done simply by clicking an edit icon on a fully WYSIWYG page.

Generally Gate Seven would expect to deliver a system which was fully configured at the Admin level, and which would normally require minimal intervention from the Admin.

• content can be added and modified behind the scenes before publication,
• everything done to a site can be reversed in case of rash actions,
• The page-tree model is intuitive when adding or moving pages
• The appearance of the whole site, or part of it, can be modified by selecting an alternative template, on a page-by-page basis
• Editors work with word-processor like editors, and/or fill in forms
• Menus for site navigation are generated automatically based on the position of pages in the page tree

TYPO3 has an extensive logging system which records all modifications (and allows them to be rolled back).

Very little is ever actually deleted.

The logging system can be augmented by the versioning system, which allows arbitrary versions of pages to be defined, worked on simultaneously, and swapped with the currently published version.

Permissions in TYPO3 are granular, so it is possible to set them up to support numerous types of work flow. The editing functions can be separated from the publishing functions, and publishers can request editing (or translation jobs) from individual or groups of editors, if the work flow extensions are installed.

The process works by sending emails automatically to the appropriate people, when a job is requested, when it is assigned, and when it has been completed.

Generally, TYPO3 does not impose particular roles on users, but rather gives admins the flexibility to define roles in accordance with the client's business model.

The major divisions are:

• Admins (who can change anything) and
• other backend users (who can change whatever they are allowed to change)
• backend users may be members of user groups, which define what they can change
• Front-end users (who, once they are logged in to the system, may be given permissions to view, add, edit, or modify some content), based on their membership of front-end user groups

• All pages can be marked as invisible. If this is so, they can be previewed from the backend.
• Using the Workspace system, pages can be worked on in the background, and previewed either alone, or in direct comparison with the currently published page
• Using the Versioning system, multiple versions of the same page can be maintained, edited independently, and previewed.

Links can be divided into those that the system generates (for menus/site maps of various kinds), and those which are inserted by editors, either within textual content, or  as part of  extensions which categorise and display lists of links.

The first type are completely contextual, and generated automatically, based on the page tree, or sometimes on lists added by the admin. If a page is removed or marked as invisible, all menus generated by the system immediately reflect that.

Other links can be divided into:

• Links to pages or content elements within the site.
• Links to files for downloading
• mailto links
• Links to external sites

Links to internal pages or files stored on the server are set up by a point-and-click method based on the page tree/file structure, and are therefore unlikely to be bad. However, once set, a link cannot directly know if its target actually exists, since the target may be deleted (apart from any other considerations) in any number of ways which are out of control of the CMS.

Extensions which manage external links usually have the means for users to report if the are broken.

In terms of internal links to files, it may be productive to consider that, as a policy, files added to the file system should not be deleted, and that access to them should be controlled; this is the model which the CMS itself actually uses: ?deleted? elements are marked as deleted in the database, but not actually removed. In relation to documents, links being added or subtracted is equivalent to adding or deleting the file itself, since it controls access to the file, and the file itself could only be accessed if someone knew the correct path to it.

It would be possible to extend the crawler extension (which is normally used to regenerate the cache of each page overnight) to check all pages for internal links to files, and then check that the files themselves still exist, and take appropriate action of they do not, though the action could obviously not extend to rewriting the link text appropriately (the link text normally says something like ?click here to ??, so just removing the link itself does not actually work) 

A portal usually involves a front page which is designed to keep users up-to-date with what is going on in the rest of the website, and the field generally, by means of small teaser entries ? usually a picture, a summary, and a title, which are linked to the main entries. There might also be menus of the latest updated items, and the most popular.

A portal page is usually more complicated in structure than other pages on the web site, because the teasers need to be organised in additional vertical columns.

All these objectives can be accomplished straightforwardly: extension for news, links, events and calendar have ?front-page teaser modes?, while other types of menu for insertion in pages can be used to tease particular pages, or the most popular, or most recent.

Flexible content elements, a part of the templating system, enable content areas to be further subdivided into additional vertical columns to accommodate these (usually narrower) elements within the site?s standard templates

One advantage of a CMS is that processing happens on the server, not on the users? computer. Making the system suitable for dial-up connections is largely a matter of discipline on your part. Avoid extensions which rely on large amounts of javascript, (or at least ensure the javascript is in an external file, so only needs to be downloaded once) keep formatting in the CSS, set image quality to default to the lowest acceptable level, use text-based (CSS styles) menus, and avoid fancy javascript-based flyout menus. (The situation may be a little different if your editors, and particularly, administrators, have dial-up connections, since the back-end interface is necessarily more complex.)

TYPO3 defaults to XHTML 1.0 Transitional. Other DTDs are possible, but require more work - mainly modifying extension (X)HTML templates so that their output is conformant with the appropriate standard.

We adopt CSS-based table-less layouts and other measures to ensure compliance with semantic web considerations, and adopt measures to comply with accessibility requirements.

In turn, editors need to ensure that they conform to accessibility standards - by including alt test for graphics, for example.

By basing our layouts on the YAML framework, we can ensure support for the following browsers:

Windows

Internet Explorer 5.01

Internet Explorer 5.5

Internet Explorer 6.0

Internet Explorer 7.0

Internet Explorer 8.0

Macintosh OS

Safari 1.0.3+

Camino 0.6+

Linux

Konqueror 3.3+

Galeon 1.3+

Epiphany 1.4.8+

Lynx (Textbrowser)

All operating systems

Firefox 1.0+

Mozilla Suite 1.7.1+

SeaMonkey 1.0+

Netscape 8.0+

Opera 6+

Safari

Google Chrome

YAML's CSS building blocks use the rules of @import or @media to deal with the problem of outdated browsers. Internet Explorer 5/Mac, Netscape 4x, and many other outdated browsers are incapable of interpreting one or the other of these rules, and so are automatically shunted away from the modern CSS declarations. Users see the complete content: unformatted, but legible.

In short: outdated browsers are supported by YAML in such a way as to allow users to read the content without being hampered by incomplete CSS interpretation. Content is visible in the browser's standard design, similar in appearance to text browser interpretations (i.e. Lynx).

For the reasons stated above, YAML layouts are compatible with most media. Perhaps most important, they work with printers, since stuff which is not needed such as menus is set to be invisible, while the columnar layout is replaced by a sequential vertical layout.

If you needed more than this, the possibility exists to define page types in TYPO3, and this allows the same page structure to deliver different content depending on the connecting device. One of the standard page types is for very small screens; but at this point you probably don?t want to go that far.

The extension css_handheld_switch enables you to switch your css files to those appropriate for hand-held devices, and also logs the types of devices that are connecting to your site.