Yesterday I spent some time working on my seo_basics extension and on the last fixes for the upcoming DAM (Digital Asset Management) version 1.1 — a beast of an extension,  but good for adding metadata to uploaded files. While there was a huge movement in May and June, things kinds slowed down in the last months, and Ben pushed the whole thing a bit more. In any case, 1.1 will be a bugfix release (with a dependency on TYPO3 4.2.2 or later) marking the way for a glorious 1.2 (Release TBA ;-)).

After testing and commiting couple of patches, I looked into one other issue, namely to hide certain fields when editing a DAM record. Although the DAM has its own module and submodules, it uses the default TCEforms for editing metadata of files. If you decide to hide certain fields from your editors (and / or admins), there are several ways to do so. First of all, you can probably configure it through the huge excludelist of a Backend usergroup. Somehow, I got away from using excludelists, as it’s just a pain. The variant I like more is to use an approach to hide fields in TCEforms through pages TS config. This way you can hide all fields of a table that is listed in the TCA. It’s not preventing a BE user (rights-wise) to edit a certain field in the BE, but as he won’t see the field anyways I figured that this is enough for most cases.

For the DAM, all metadata (DAM) records are in the DAM media folder in the page tree. This one is sometimes hidden, depending on your installation. If you don’t see the “Media” folder in the page tree, go to the Extension Manager, edit the Install-time options of the DAM / Media Extension and disable the checkbox “Hide Media Sysfolder”. After that, you can select the media folder. Edit its page properties (it’s nothing else than a sysfolder anyway, btw). Select the “options” tab, where you can add the pagesTSconfig. With a

TCEFORM.tx_dam.publisher.disabled = 1

the publisher edit field won’t be rendered when editing a metadata record. Oh yeah, this of course works for all other TCA tables as well. I use it in the page properties to remove all language-related fields in an installation with only one language to help unclutter the interface.

A complete list of all fields to disable the DAM is attached here:

TCEFORM.tx_dam {
    hidden.disabled = 1
    starttime.disabled = 1
    endtime.disabled = 1
    fe_group.disabled = 1
    sys_language_uid.disabled = 1
    l18n_parent.disabled = 1
    l18n_diffsource.disabled = 1
    t3ver_label.disabled = 1
    media_type.disabled = 1
    title.disabled = 1
    file_name.disabled = 1
    file_path.disabled = 1
    file_dl_name.disabled = 1
    file_type.disabled = 1
    file_type_version.disabled = 1
    file_size.disabled = 1
    file_orig_location.disabled = 1
    file_orig_loc_desc.disabled = 1
    file_creator.disabled = 1
    file_mime_type.disabled = 1
    file_mime_subtype.disabled = 1
    file_ctime.disabled = 1
    file_mtime.disabled = 1
    file_usage.disabled = 1
    ident.disabled = 1
    creator.disabled = 1
    publisher.disabled = 1
    copyright.disabled = 1
    keywords.disabled = 1
    description.disabled = 1
    caption.disabled = 1
    alt_text.disabled = 1
    instructions.disabled = 1
    abstract.disabled = 1
    date_cr.disabled = 1
    date_mod.disabled = 1
    loc_desc.disabled = 1
    loc_country.disabled = 1
    loc_city.disabled = 1
    language.disabled = 1
    hres.disabled = 1
    vres.disabled = 1
    hpixels.disabled = 1
    vpixels.disabled = 1
    color_space.disabled = 1
    width.disabled = 1
    height.disabled = 1
    height_unit.disabled = 1
    pages.disabled = 1
    meta.disabled = 1
    category.disabled = 1
    parent_id.disabled = 1
    deleted.disabled = 1
    index_type.disabled = 1
    file_inode.disabled = 1
    file_hash.disabled = 1
    file_status.disabled = 1
    tstamp.disabled = 1
}

Although this is pretty simple and straightforward, some might want to use this. As far as I know there is currently no (easy) way to change the visibility of the fields in the other screens. Nevertheless, watch out for an updated version of the DAM, going with the latest (also soon to come 4.2.2) TYPO3 core in the near future.

Tip 1: You want to link to the same page, but with JS params etc,

lib.mytext = TEXT
lib.mytext.value = This is a link
lib.mytext.typolink.parameter = {TSFE:id},775 500x600 selflink
lib.mytext.typolink.parameter.insertData = 1

I had to use this idea when having a big site with a lot of microsites where the client is able to clone a microsite without needing to configure any IDs. The typolink.parameter = this,775.. did not work.

Basically, with this project, I had to make sure that no page IDs were hardcoded in TypoScript, so it was easy to create a new site inside TYPO3.

The following example renders a menu based on keywords (there was a requirement about the page titles) instead of a special = directory type of menu.

lib.rightnav = HMENU
lib.rightnav {
  special = keywords
  special {
    value = 1
    depth = 2
    setKeywords = Contact,Newsletter
    keywordsField = title
    entryLevel = 0
  }
  1 = TMENU
  1 {
    alternativeSortingField = sorting
    noBlur = 1
    NO.allWrap = <li>|</li>
    wrap = <ul class="rightcol_contact">|</ul>
  }
}

The next example shows a tt_news to link to the first subpage as the “single page”.

plugin.tt_news.singlePid.cObject = HMENU
plugin.tt_news.singlePid.cObject {
	special = directory
	special.value.data = TSFE:id
	maxItems = 1
	includeNotInMenu = 1
	1 = TMENU
	1 {
		NO.doNotLinkIt = 1
		NO.stdWrap.field = uid
	}
}

I know it’s not big magic and can be solved differently as well, but it just keeps me busy these days

http://www.b13.de/index.php?id=25

Well, we all know that search engines don’t like it and visitors don’t find it as convenient as having a real URL, that looks like that

http://www.b13.de/en/about/downloads/
http://www.b13.de/en/products/saviour-v1/

Great! Let’s do this. RealURL does everything for you. Very simple and good (and bug-free — I love the latest version, thanks Dmitry!). However, if you’re on the downloads page and want to link to the products detail page, then the link will look like

http://www.b13.de/en/about/downloads/en/products/saviour-v1/

The reason is that realURL (or let’s say, your browser) does not know where the root of your installation is. realURL suggests using the <base href=”http://www.b13.de/”> tag to let the browser know that all relative links are relative not to the current page but to the specified base href. You can configure this in TypoScript with config.baseURL = http://www.b13.de/ and then there you go.

This all works fine — and if you have multiple domains, you just need to use TypoScript conditions, but this is all doable. However, in the recent past a few of my clients (NOTE: only the ones with 404 pages managed through TYPO3) ran into problems with strange floods of their log files with zillion 404 calls. The reason was that there are some bots that don’t interpret the baseURL tag, and then call the non-existent URLs (e.g. images), which redirect to the 404 which also includes the 404 path. Yes, quite annoying.

So, I was searching for an alternative. Dmitry posted some information on his blog about this error as well. The htaccess redirect he mentioned worked just fine, but I really wanted to avoid this in general, asking a simple question: “Can’t I just set a slash (/) in front of every URL and file reference of my generated HTML?”. This was something I actually wanted before I used this baseURL configuration option (yes, a long time ago). And, in fact, there was this option “config.absRefPrefix” lying around the whole time, and I never used it. As you can see there are so many things you find every time in TYPO3. With the absRefPrefix option I don’t even need to bother with the domains if I just use

config.absRefPrefix = /

or

config.absRefPrefix = /path/to/my/t3installation/

depending on the location of the TYPO3 mainsite directory. But it looked like it’s not that easy, because I ran into some issues (after switching 4 or 5 sites from baseURL to absRefPrefix).

• You need to have the latest realURL version and set the “reapplyAbsRefPrefix = true” in your realURL configuration array to keep the prefix.
• Linking between domains is not as smooth anymore as with the latest realURL and 4.2
• If you have references to typo3conf/ext/, they won’t be prefixed. I ran into this by having: <link rel=”stylesheet” type=”text/css” href=”typo3conf/ext/rgmedialinks/res/mediabox.css” />. I noticed that this is a bug in the TYPO3 core, so I fixed it.
• There are still some errors if you use custom extensions. You need to make sure that these work. I had trouble with mailforms and some custom scripts that alter the “img” tag, because the URL wasn’t typo3temp/ anymore but http://www.b13.de/typo3temp, so some default replacements didn’t work anymore. Nothing serious, but just something to keep in mind.
• The latest issue that the Magic images I added during the baseURL times with the htmlarea RTE didn’t work anymore. A simple htaccess redirect (RewriteRule ^(.+)uploads/(.*?)$ /uploads/$2 [R,L]
  ) worked just in this case.

In my eyes, the real and true solution would be to

1. get rid of all baseURL tags (in my eyes, it was and will always be just a dirty workaround).
2. have realURL add the part of the mainsite directory to every relative path when rendering the HTML. There could be an option for multisites to dynamically add the domain to all links, using the domain records.

TCEFORM.tt_news.category.config.minitems = 1

This can be done on pagesTSconfig level but also on userTSconfig, and is quite helpful to save some support calls.

lib.newstitle = RECORDS
lib.newstitle {
    dontCheckPid = 1
    tables = tt_news
    source.data = GPvar:tx_ttnews|tt_news
    conf.tt_news = TEXT
    conf.tt_news.field = title
    conf.tt_news.required = 1
}

This renders the tt_news title if there if there exists one. This can easily be attached to anything else in TypoScript, to a breadcrumbs menu for instance:

lib.breadcrumbs = COA
lib.breadcrumbs.10 = HMENU
lib.breadcrumbs.10 {
    special = rootline
    special.range = 1
    1 = TMENU
    1.noBlur = 1
    1.NO.linkWrap =  > |
}
lib.breadcrumbs.20 < lib.newstitle
lib.breadcrumbs.20.conf.tt_news.wrap =  > |

And boom, there you go. Same goes for any pagetitle. The nice stdWrap option “.required = 1″ also only adds the “.wrap” option if the title is not empty.

Btw… thanks to Bob who had this issue on the typo3 tt_news newsgroup this week!

As of the nature of TYPO3, an installed skin just overrides the classic skin styles and icons, and it seems like the t3skin author forgot about that. The places where you can see these problems is when selecting a link (Element Browser, Browse Links) and inside the DAM. Apparantly these are the only occurences where the “tabMenu” functions from the template.php file are used, all other places (TCEforms) use the dynTabMenu whic is styled.

However, I found out that I only need to add some CSS markers then to make it integrate nicer in t3skin. This came up two weeks ago when we met about the t3skin and the Backend Usability in Arnhem. I dove into it and found out about the use of tabMenu and the missing CSS in t3skin. Below is a before / after screenshot comparison. Aaah, I like it!

Be sure to check out TYPO3 4.1.7 and 4.2.1, arriving next monday, which finally include the fix (just commited that patch this morning). One patch closer to a better world…

• Pre 2004: Kept everything in my HTML file
• 2005: Had a marker in my HTML file, that my TEMPLATE object replaced
• 2006: Used TemplaVoila with defined footer fields, matching a TS object (lib.footer)
• Post 2007: Used stdWrap effectively for my lib.footer object

This is how it looks like if you just need a “self-updating” footer:
lib.footer = TEXT
lib.footer {
data = date:U
strftime = %Y
wrap = © |  b:dreizehn GbR • More stuff
}

The TEXT object has stdWrap methods at the base level, so I took “date:U” from the “getData” type, ran it through a strftime and wrapped it in my HTML code.

For many years (actually until 2006), most parts of stdWrap were a closed book for me, but if you read the source code itself, it all comes down to you. So simple, so powerful. Check out the source in your TYPO3 package (”typo3/sysext/cms/tslib/class.tslib_content.php”).

Quite simple, and if you think about it, you could have done that by yourself easily, right?

However, that’s not all that you can do with TypoScript, more to come…

I had the problem that I needed to redefine some labels for alanguage file in an extension. This was client-specific, so it wasn’t suitable for a patch to send to the corresponding extension developer. But I didn’t want to modify the extension files by myself, because in case of an upgrade, the changes would have been erased. So I stumbled upon this nice feature, which worked just fine for my TYPO3 4.0 installation.

The idea is that you can specify an “override language label file” that TYPO3 loads directly after loading the labels of a specific file. It then overwrites the labels that were added in the file, but keeping the ones you didn’t touch. You only have to add this one line to the typo3conf/localconf.php.
$TYPO3_CONF_VARS['BE']['XLLfile']['EXT:sr_feuser_register/locallang_db.xml'] = \
‘typo3conf/my_custom_labels.xml’;

The XML file itself looks like this:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
  <T3locallang>
    <meta type="array">
      <description>Custom Labels especially for this installation</description>
    </meta>
    <data type="array">
      <languageKey index="default" type="array">
        <label index="fe_users.gender">Gender:</label>
        <label index="fe_users.gender.I.0">Mr</label>
        <label index="fe_users.gender.I.1">Ms</label>
      </languageKey>
      <languageKey index="de" type="array">
        <label index="fe_users.gender">Anrede:</label>
        <label index="fe_users.gender.I.0">Herr</label>
        <label index="fe_users.gender.I.1">Frau</label>
      </languageKey>
    </data>
</T3locallang>

After that, clear your cache and the labels will be changed… I know, somebody would now tell me that you can do this with pagesTSconfig (for the Backend) or TypoScript (for the Frontend), but she/he is wrong here. Why? The pagesTSconfig only works with TYPO3 4.2 and later. Also, with this awesome method it is possible to also change labels for e.g. the “Clear cache” menu in the backend.

Very nice, huh?