TYPO3 stdWrap explained

stdWrap is one of the most powerful and at the same time obscure TYPO3 functions. In these series of articles I am going to make this function more clear for both TypoScript and extension developers.

What is stdWrap?

stdWrap is a TYPO3 function that can alter data or replace it with completely another data if developer wishes so. stdWrap is incredibly powerful. It can do many transformations, check conditions, use content objects and many more. If there is no transformation that developer needs, it is always possible to extend stdWrap with a custom function.

A most simple example of stdWrap is:

temp.test = TEXT
temp.test {
  value = Hello, world!
  wrap = The boring phrase: "|"
}

This will produce the "Hello, world" prepended by "The boring phrase".

I am sure you used it wrap property a lot but have you realized that you actually used stdWrap?

Yet Another Feed Importer

On Friday I posted another extension to TER. It is called "Yet Another Feed Importer".

Why having "yet another"?

I needed an importer that will be easily customizable and extendable from the outside. In "yafi" (extension key for the new importer) I provide a framework and use plugin pattern to do imports. Take a look to the diagram:

How to kill TYPO3 performance from extension

Today I went to check buzz.typo3.org for new articles. I scanned through some when I came across the article named "Dynamic Caching in TYPO3". The article is interesting because it describes unusual techniques related to caching. But author does one "not-so-good" thing. He promotes the use of $TSFE->set_no_cache(). As I said many times, this is evil and should be avoided at all costs! Search for another solution, do whatever tricks but never ever use set_no_cache()! It will kill your web site under any serious load.

It is not a big problem for the particular case described in that article. In the article this function will be used only for a logged-in user who views his own card. But readers may learn about the function and start using it in extensions without realizing what they do. That's bad. We had a problem some time ago in commerce extension, which disabled caching for the whole web site and made the site extremely sloooooooow and created huge load on the server. Bad. Too bad. I wish all writers make a bold warning when mentioning this function: dangerous!

Last week I made a performance review of yet another web site and yet again (again and again!) I found problems caused by misuse of set_no_cache(). It was found in three extensions (download, link list and one proprietary). It is typically the set_no_cache-case when people ask why their site has such a bad performance. If it only were in my power, I would go to TER and remove all extensions that use set_no_cache().

Don't use this function! It is for core only! It is not for you! Avoid at all costs!

Why would you choose TYPO3 for you next web site?

"Why should I use TYPO3 and not some other CMS?" or "My boss wants to know why we should use TYPO3?" These questions appear in TYPO3 _mailing lists_ from time to time. It is no doubt that TYPO3 is a very powerful CMS. I would even say that it is the most powerful CMS in the world right now. But power alone is not a very big reason to use TYPO3. Even if TYPO3 is the most powerful, does it serve well? It serves many web sites on the Internet. But will it be able to serve ~your~ web site? Will it be able to server your web site ~better~ then other CMS? This is the first question you want to be answered. You would like to know if TYPO3 is the right choice specially for you and why it is the right choice specially for you.

What TYPO3 Backend do we need?

There were some discussions during T3DD08, in the mailing lists and by Skype that we need some changes in TYPO3 UI. I was fighting my points hard. One of my points is: change existing and stable things only if it is absolutely necessary because people are already used to them.

I am not talking about bug fixing here. Bug fixes usually do not force people to learn new things. I am talking about changing UI in the incompatible way.

One good (or bad, depending on your views) example is repositioning of "Exit" button" in TYPO3 4.2. It took me several minutes to find this button in the 4.2 Backend. I am not a newbie as you know. The button was placed in the zone, which (according to studies) is least seen by people. It was placed to top-right. It took over 20 minutes to some of my editors to find and they are not stupid!

Another example is the rush with "tabs everywhere" and "docheaders everywhere". It caused many people to complain: they have to make more clicks now. This problem was definitely was not well-thought by developers.

RealURL made easy: part 2

This a part two of the “RealURL made easy” series. In the first part we reviewed how url is constructed using RealURL and saw what are main configuration directives. This part will show practical steps to create a good RealURL configuration. The next (3rd) part will teach you some neat configuration tricks. But first we have to create the configuration.
From RealURL perspective all installations can be divided into to groups: single-domain tree and multi-domain tree. Single domain tree is the simplest and we already saw how to configure single domains for RealURL using _DEFAULT keyword.
Multi-domain configuration is more complex. Typically sites in a multi-domain setup share the same set of preVars and postVarSets. fixedPostVars (if used at all) are different because fixedPostVars should be specified for the specific page (this is covered in part 1). Therefore we will concentrate on this typical case here.
The steps for setting up multi-domain RealURL configuration are:

• create a prototype for configuration
• collect all domain names and root page id values
• configure main domains
• efficiently configure aliased domains

Health care software for programmers

Some time ago I come across two programs and I would like to share my experience with the TYPO3 community. These programs help computer specialists to keep better health and improve life quality.

Migrating a TYPO3 installation to a different server

This article tells how to migrate TYPO3 installation to another server. It assumes that you are in charge of the server. If you use shared hosting, it may be harder to migrate because you do not have anough control. In short migration consists from the following parts:

• Migrating files
• Transferring the database
• Recreating directory structure
• Updating the installation

Let's see these sections in details.

Installing TYPO3 with upgrades in mind

TYPO3 releases a new version every year or year and half. The system is not the smallest one and upgrading it may not the easiest task. In this article I want to show how to install TYPO3 with upgrades in mind.

Logically TYPO3 installation consists from two big parts: the core and site-specific files. The core is released by TYPO3 core team and it is not changing. Site-specific files is what web site owner creates in order to have a running web site under TYPO3 control. Inside the file system these parts should be seen as a single set of files.

The core is distributed as a compressed archive by TYPO3 core team. When new version is released, this part should be upgraded. However simply extracting files over existing installation is not the way to upgrade. Sometimes TYPO3 files change, so file can be removed, new files can appear. Extracting files to the existing location is not a good way to keep stable TYPO3 installation.

Ideally core files should stay as a package, separate from the site-specific files. Than core can be easily replaced independently from the rest of the site. But how to make the core separate and still keep the proper site structure?