tooltips with ext:contagged

for some reason the very good extension contagged does not provide the dropdown to select what type of term the current item is. so all my entries in the sysfolder “terms” have type 0.

the little tweak in the userTS changes all newly created terms to be a tooltip:

TCAdefaults.tx_contagged_terms.term_type = tooltip

a small UPDATE in mysql made the already existing terms to tooltips as well. a post before i saved how to have only contagged items in this sysfolder.

to avoid editor´s overkill when just creating a little tooltip i also remove some fields from the very flexible contagged terms item in PageTS:


TCEFORM.tx_contagged_terms {
 image.disabled = 1
 imagecaption.disabled = 1
 imagetitle.disabled = 1
 imagealt.disabled = 1
 exclude.disabled = 1
 term_type.disabled = 1
 term_replace.disabled = 1
 desc_short.disabled = 1
 starttime.disabled = 1
 endtime.disabled = 1
 fe_group.disabled = 1
 sys_language_uid.disabled = 1
}

i also do hide fe_group access dropdown and the system´s language selector thus making the backend experience more simple.

keep TYPO3 sysfolders clean

just a small hint to restrict the creation of new elements inside a page (eg. a sysfolder) so that this sysfolder will only hold tt_news entries or sys_templates or whatever. you put that code into the pageTS of the sysfolder/page:

mod.web_list.allowedNewTables := addToList(sys_template)

if you´d like to only contain tt_news entries and tt_news categories you´d put addToList(tt_news,tt_news_cat) into the TS and then these are the only elements to create new inside that folder. if you want the sysfolder to hold only entries for the nifty contagged extension, you use addToList(tx_contagged_terms). here´s more on contagged as tool tip manager.

15 ways to point out TYPO3 is your drug

  1. You mostly guess whether a page you surf on was made using TYPO3, and you always check, what year is stated in the header comment
  2. You leave the “admin” account active on your systems, but remove all privileges and set the password to something like “hackme&bugoff!”
  3. You have at least one system on which the sys_template´s uid went over 250
  4. You have subscribed to more than 50% of the newsgroups on lists.typo3.org
  5. Your conditional sentences have virtual squared brackets around it
  6. You try to convince your customer to make use of even the table content element
  7. You usually sleep tight on your TYPO3 pillow
  8. Your vision is #69A550 and #FF8700
  9. You categorically do not apply with a company that misspells TYPO3
  10. You try to solve real world problems with TypoScript
  11. You have or at least have had once an account password set to “joh316″
  12. You wave aside the giggly idea of writing an own TYPO3-like cms from scratch
  13. You clear all the cache, if you come to the conclusion your servers idle too much (not at peak times, of course)
  14. You smile when it comes to stdWrap
  15. You always have the extension kickstarter installed, just for the case

i´d like to you read your drug test cases – no blood, no hair, no police :-)

get user ip from behind reverse proxy setup

small problem, wide reach. if your TYPO3 is set up behind a reverse proxy (like pound) and you need the ip connection information of the visitors, T3´s userfunction method comes in handy.

fileadmin/scripts/fwdip.php


<?php
class user_fwdip {
 var $cObj;
 function main($content,$conf){
  $ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
  return $ip;
 }
}
?>

This is the file you´d like to ask for the ip from within TYPO3.

To be able to use this file in a userfunc style you´ll need to include the file in TypoScript, i put it into an own TS template on one special page.


page.includeLibs.fwdip = fileadmin/scripts/fwdip.php

You now could put the stuff on the same TS template but i recommend this neat extension to generate the output to one special page in a content element. The extension wraps the TS in a COA.


20 = USER
20 {
 userFunc =user_fwdip->main
}

Now the page you put the element on should show your real ip address, instead of the proxy ip.

Simple, but fully worth a snippet.

typoscript condition with constants

small snippet great effect to your typoscript. i use this to spare lines of executed typoscript if the editor won’t use it anyways. in my opinion it’s not only a great tool for extension development, but also it can restructure parts of your ts setup of the site.

constants:

SHOWBADGE = 1

setup:


# only work out stuff for SHOWBADGE is true

[globalVar = LIT:1 = {$SHOWBADGE}]

page.10.marks.A < lib.showBadge
# etc...
[global]

i don’t know what the LIT:1 means, but it works. i mean, is there a LIT:2 and so on? if you’ve got crucial information on this matter, comment or mail me. thanks.

additional philosophy: what are constant conditions anyway?

list all TypoScript lines

some days ago i needed to have a complete listing of the TypoScript Constants and Setup that affect a specified page. sure, the good template-analyzer highlights the lines of a single ts template found in the rootline. but how do you display the complete TypoScript that applies to this page?

TYPO3 Template Analyzer

maybe the dirty copy/paste trick works out for smaller sites, but if the hierarchy is getting more complex you definitely don´t want to go this extra miles. so, i started my own extension to present this function. after a short while digging into the template analyzer code from kasper i was surprised as he already built in this feature of a complete listing.

complete ts listing using onboard functions

your http request to view a single template with the template analyzer looks like

http://t3/typo3/sysext/tstemplate/ts/
/index.php?id=42&template=sys_23

…or at least a bit like that. Now, if you fire up a request like this

http://t3/typo3/sysext/tstemplate/ts/
/index.php?id=42&template=all

…you´ll get what you want. It can be easy like this.

To spare you the typing by hand, you could touch the systext itself.  Add the following lines in typo3/sysext/tstemplate_analyzer/class.tx_tstemplateanalyzer.php i.e. around line 122 (after the section “Template Hierarchy” is set up).

 	$completeLink= '&lt;p&gt;&lt;a href=&amp;amp;quot;index.php?id='.$GLOBALS['SOBE']-&gt;id.'&amp;amp;amp;template=all&amp;amp;quot;&gt;view the complete TS Listing&lt;/a&gt;&lt;/p&gt;';
$theOutput.=$this-&gt;pObj-&gt;doc-&gt;spacer(5);
$theOutput.=$this-&gt;pObj-&gt;doc-&gt;section(&amp;amp;quot;Complete TS:&amp;amp;quot;,$completeLink,0,1); 

Then visit the Template Analyzer again and click the button. Get yourself some cool or hot drink as the ts parser now works out all the TypoScript lines you asked for what could take a while.

That snippet especially comes in handy when administrating foreign pages that have not been setup by you and the object browser keeps spitting error at line xxxx in your backend.

As for me, this makes my weekend. I still wonder why this feature is not visible for the user (security/performance issues? or just forgot?) or maybe i even was too stupid to find the button. But i like this feature and the experience that the system can do even more as the gui presents me ^^

please drop a comment if you know about these concerns. See you on monday.

show author of the page if set per typoscript

just because this is a common case, i’ll post it for my own and public concern. this is the task:

show a text to contact the author of a page by (spamprotected) email if information to the author is found in the page object


temp.contact = COA
temp.contact {
50 = TEXT
50 {
value = {page:author}
insertData = 1
required = 1
typolink.title.dataWrap = {page:author}
typolink.parameter.dataWrap = {page:author_email}
noTrimWrap = |<div class="authorinfo">Could this page be improved? <br />(Pagetitle: {page:title})<br /><br />Please write to |</div>|
}
}

suppress listing of static_tables in the root page

if you’re about to work with the root page of some TYPO3 installation and, let’s say you have static_tables installed, you’re gonna get a long list of countries, markets and currencies in the root list which is fully loaded, everytime you want to administrate a backend user or a file mount – since these items are listed by default on the root page. i kinda got used to this.

but since this sucks a lot of time up in your backend session depending on server load and bandwidth, this one-liner found on the english TYPO3 mailing list can tweak your backend experience for the root page. the attempt of putting the line like “mod.web_list.static_template.hideTable = 1” into a pageTS will not work because the root page seems to have no pageTS at all.

instead, put this in the userTS of your be account  or a user group you’re member of:

mod.web_list.hideTables=static_countries,static_country_zones,static_currencies,static_languages,static_territories,static_taxes,static_markets
mod.web_list.hideTables=static_template

the tables you specify here will be gone on every page. in the case of static_* tables, they’re just to listed on the root page, anyway. so, listing your root page will speed up a lot!