Posted by & filed under TYPO3.

Nginx has emerged as one of the popular webservers to run the TYPO3 framework. Advantages to using Nginx are that it is lightweight, fast, and reliable – unlike Apache, which has a much bigger footprint in terms of resources. Nginx is frequently set up to handle static files or cached pages (thanks to its memcached module), while any dynamic requests are forwarded to Apache.

In this blog post I will describe how to set up Nginx to play a role of the load balancer, directing incoming requests to a cluster of Apache servers. There are many advantages to this set up. It allows for scalability, where new servers can be added any time to meet increasing demand (including virtual servers in the cloud). It improves reliability, since Nginx will automatically detect when a server is not responding to requests, and forward the request to another server.

Best of all, implementation would not require any changes in TYPO3 code, only basic configuration changes. I’ll skip basic installation instructions, since you can find them elsewhere on the net. If you’re on a Debian system, I highly recommend compiling from scratch due to outdated packages in default Debian repositories.

Nginx Confguration

First we add an upstream configuration to the main nginx configuration (/etc/nginx/nginx.conf on Debian):


# Load ballancer configuration
upstream backend {
ip_hash;
server 10.0.0.2:80;
server 10.0.0.3:80 down;
server 10.0.0.4:8080;
}
upstream typo3 {
server 10.0.0.2:80      weight=2;
server 10.0.0.3:80;
server 10.0.0.4:8080;
}

We define two very similar configurations: one for backend, one for frontend. First one will be used for access to TYPO3 BE so it uses ip_hash directive to send users to the same server within a certain time frame (note: this is not necessary, but its nice, and could prevent some strange bugs). This also lets us set certain servers as inaccessible using the down directive. Second definition defines a list of servers for the front end, with equal weight distribution, unless specified otherwise.

Next we need to make use of the server clusters. In your site definition (ex: /etc/nginx/sites-enabled/default), add the following:


location /typo3/ {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}
location /typo3conf/ {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}

location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://typo3;
}

Lines to notice are:


proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Which forward the Host (necessary for multi-domain systems), and the X-Forwarded-For header. We need to make use of the later in our TYPO3 configuration. Add the following to typo3conf/localconf.php:


$TYPO3_CONF_VARS['SYS']['reverseProxyIP'] = '10.0.0.1';
$TYPO3_CONF_VARS['SYS']['reverseProxyHeaderMultiValue'] = 'first';

Change the reverseProxyIP to the Nginx server address – as the Apache servers would see it. You can even set it to different values based on where the server is – for example, if you have an Apache server on the same machine as your Nginx proxy, you can set it to 127.0.0.1.

That’s it! You should now see traffic distributed across the servers. If you pull the plug on one of the servers, the site will still be up with the other servers taking on the load.

Posted by & filed under TYPO3.

Now when calling $TSFE->set_no_cache(), a reason can be provided and logged, making it easier to find why cache was disabled on a page.

Ex:
$TSFE->set_no_cache(‘Reached an unstable condition in extension xyz’);

More info:
Fix #11669: Provide a reason for why $TSFE->set_no_cache() has been triggered
http://bugs.typo3.org/view.php?id=11669

Posted by & filed under TYPO3.

New key in EM_CONF array, ‘doNotLoadInFE’ can be set to “1” for extensions that are only used in backend and have no front end components. This speeds up the frontend generation process, since extensions not doing anything in the FE will not be loaded on FE calls.

More info:
RFC #11474: Store separate extlist for the frontend
http://bugs.typo3.org/view.php?id=11474

Posted by & filed under TYPO3.

One of the major features in TYPO3 4.3 is the advanced frontend editing. Although its not part of the official distribution, it is available as an extension, and adds amazing functionality to your TYPO3 driven site. But did you know that you can edit any other record in the frontend using feeditadvanced functionality? Here is some simple TypoScript code that allows you to edit tt_news records from the frontend:

plugin.tt_news.displayList.title_stdWrap.editPanel = 1
plugin.tt_news.displayList.title_stdWrap.editPanel {
editPanel = 1
allow = edit,hide,delete
line = 5
label = %s
onlyCurrentPid = 0
previewBorder = 4
edit.displayRecord = 1
}

Here is what you will see in the frontend, next to each tt_news title marker:

feedit_ttnews_1

And if you click edit, you will get a standard form allowing you to modify the record:

feedit_ttnews

Generally, any record that has stdWrap properties can be wrapped in this code to enable FE editing.