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

Usability bugs

From TYPO3Wiki
Jump to: navigation, search

This is a list of usability bugs, that are mostly too small to be extensivly discussed in the mailinglists but still could/should be improved for the upcoming "ease of use" improved version 4.5 of TYPO3. Feel free to add, edit or comment these issues!

notice - This information is outdated

While some details may still apply in specific situations, this page was written for packages of TYPO3 that are no longer current.


  • no default page targets like PAGE_TARGET = xy. There are many places where default content elements have strange targets. +4
  • no default blurlink() output - not necessary for most projects -1 (-> add a TS to do that.. )
  • no default doctype, does not hurt if not present and can be set manually very easily -3 (is there a TS to avoid it beeing outputed?)
  • in general - no default output except the typo3 message? -3 (i really don't like having more work than needed ;-)) (-> Solution: config.disableAllHeaderCode = 1 )

(--> TYPO3 should be backwards compatible.. ..shouldn't it?)


  • move setup field above constant field - i guess 95% of the people use this field more often. -2 (use the template module, not the list module) (why not merge both fields? TYPO3 could change it's TS syntax..)
    • Quoted from the the Thread:
I don't think moving it is such a good idea (others have explained why).
However, to solve your problem, I have an alternative suggestion (other
than using the template module, which has also been suggested by others):

A collapsing feature would be excellent in the backend.
Put a plus/minus (depending on whether or not a field is 'collapsed') in
the header of the fields (see mock up screen shot at end of email)
Then people can hide the fields that get in their way.

Just putting the icon/link/whatever in the header to
collapse/un-collapse the field is a start. But to go even further, it
needs to be configurable by TSconfig (per user/group AND per page)

so two steps:
1) Icon that collapses/un-collapses in field header
2) Add TSconfig to control it


  • make "include extension template" etc. easier accessed by creating a link in the overview where "constants" "setup" "template title" etc. is at the moment (so you don't have to load the whole form, when you simply want to add an extension template) +1


  • complete xhtml compliant standard wraps as light weight as possible +1 (no "/clear.gif" etc... by default)


  • remove the wrapped div of extensions by default. I had many cases where this breaked my layout and added unnecessary complexity. Well done extensions and templates (and thats what we want, do we?) don´t need fancy default styles. Most things can be easily done with a well made "masterstylesheet". -1 (there should be a TS for that)

Quote from Joey on the hci emaillist regarding this issue:

Suggestion: Change the default behaviour of the Kickstarter to always use a COA/COA_INT as the base for a plugin/new element. There could be a default Wrap that can be removed with TS easily.

For cached Elements the default should be

plugin.whatever = COA
plugin.whatever {
    stdWrap.wrap = <div class="tx_whatever_pi1">|</div>
    stdWrap.required = 1
    10 = USER
    10.userFunc = tx_whatever_pi1->main

for non cached Elements it should be

plugin.whatever = COA_INT
plugin.whatever {
    stdWrap.wrap = <div class="tx_whatever_pi1">|</div>
    stdWrap.required = 1
    includeLibs = tx_whatever_pi1.php
    10 = USER
    10.userFunc = tx_whatever_pi1->main

This way we could get rid of USER_INT Elements _and_ have more flexibility while wrapping the element or adding properties to it.

+1 Comment: I´d rather see it the other way around. For cleanness and "predictability" for users who never worked with typo3 its better to have no default wraps. that would also gently invite programmers to rely on the standard tags instead of introducing masses of very specific styles.


  • if RTE edit in HTML mode nothing of the output should be touched by default (except filtering <script> maybe). -1 DISCUSS: why not? if you don´t want to let users change the html disable this option, else its not intuitive that html input will be crippled in *some* ways.