Posted: February 16th, 2012 | Author: tolleiv | Tags: debug, typo3 | 10 Comments »
When you work on TypoScript templates in TYPO3, errors might show up in the TypoScript Object Browser. Within the error messages you’ll see a more or less detailed error description with the related line number. Within most setups these line numbers won’t relate to any of your sys_template records or TypoScript files directly. But they still provide value if you know how they help to find the right spot. As it’s not too obvious how to find the right spot I’ve created a little screenshot series to guide you to the broken spots in your templates.
So that’s what you might see in your TypoScript Object Browser:
Switching from there to the Template Analyzer:
At the bottom of the Template Analyzer, you’ll find a “Complete TS” section and a link ~which looks like normal text.
Clicking on that link will give you the entire concatenated TypoScript and here you’ll also find that the line numbers finally match to the error message.
A well hidden gem which works most likely in all TYPO3 4.x versions 
Edit: In the meantime, Ingo’s patch made it through the review process. So users of TYPO3 4.7 and above will find a nice and handy “Show details” link next to the error message. Makes it much much faster to find the broken spot. Thanks Ingo
/ (
@irnnr)
When you work on TypoScript templates in TYPO3, errors might show up in the TypoScript Object Browser. Within the error messages you’ll see a more or less detailed error description...
Posted: January 23rd, 2010 | Author: tolleiv | Tags: apache, debug | Comments Off
Once a month someone is asking because he has issues to get his mod_rewrite rules to do what he want’s. Writing the rules and the required RegEx for these rules is quite easy, but Apache still behaves strange every now and then and that’s where one of my favorite ways to “debug” mod_rewrite comes in very handy. And I felt that writing something is better than having a silent blog
The following block is what it’s all about. It seems to have it’s origin on WebmasterWorld and Rob Russel’s Blog and looks basically like this:
RewriteCond %{QUERY_STRING} !vardump
RewriteRule (.*) http://www.example.com/$1?vardump&reqhost=%{HTTP_HOST} [R=301,L,QSA]
Pretty easy and quite nice. The first line just prevents recursion, so that you’ll be able to see the first redirect and nothing else. The second line is where you can place in every information you’d like to check. The [R=301,L,QSA] makes sure that you can debug without interruption. The “R=301″ makes sure the browser doesn’t start a second request, but tells him that the location was changed, the “QSA” makes sure that the querystring isn’t lost and the “L” prevents that your server performs other redirection rules.
As shown the first block already unveils some information and places it into the redirection URL, so you could use it to check what the value of HTTP_HOST is and you also know whether mod_rewrite works or not. This way you can debug every variable mod_rewrite offers and you can check environmental variables and results of the regular expressions.
If you’d like to know whether a specific RewriteCond is working or not just place it in that block and you’ll see if it’s still redirecting or not, like this (via):
RewriteCond %{QUERY_STRING} !vardump
RewriteCond %{HTTP:Accept-Language} ^de.*$
RewriteRule (.*) http://www.example.com/$1?vardump&languageMatchedDE [R=301,L,QSA]
Checking a regular expression from an RewriteCond looks like this (used on a server with a pretty strange setup for %{DOCUMENT_ROOT}):
RewriteCond %{QUERY_STRING} !vardump
RewriteCond %{REQUEST_FILENAME} ^(.*\/htdocs\/).*$
RewriteRule (.*) http://www.example.com/$1?vardump&reqfilename=%1 [R=301,L,QSA]
As you see that’s a pretty handy way to debug lot’s of mod_rewrite stuff, it helped me quite often and I hope it does the same for you
Once a month someone is asking because he has issues to get his mod_rewrite rules to do what he want’s. Writing the rules and the required RegEx for these rules...
