How to include a custom PHP script in TYPO3

This article is covered in detail in the “doc_core_tsref” here:

http://typo3.org/documentation/document-library/references/doc_core_tsref/current/

Check the article “1.12. PHP include scripts” and 1.13. Case story for detailed info.

In short we can easily include a script in two ways.

Both these code must be written in the setup section of a template record.

  1. Using the CONFIG object.
    ex:
    config.includeLibrary = fileadmin/templates/myscript.php
  2. Using the PAGE object.
    ex:
    page.100.file = fileadmin/templates/myscript.php

That should do the trick. Fo more info I suggest that you please refer “doc_core_tsref“.

Syntax for ext_conf_template

The Syntax inside the file ext_conf_template.txt is exatcly same as the syntax for the TypoScript constant declarations.

There exists a documetnation about the same titled “Declaring constants for the Constant editor” which can be easily located in the typo3 core documentation titled “TypoScript Syntax and In-depth Study – doc_core_ts”.

Enabling Color Picker in HTML RTE Area of Typo3

By default the color picker woudl be enabled in the Typo3 RTE. However, on some cases this may be disabled. Here is a quick overview on how to re-enable it in such cases.

  1. You are unable to see the color picker, that means you need to add it to the list of available buttons.
    This can be done by adding “textcolor” to the list of existing buttons in showButtons property.
    ex:
    RTE.default.showButtons = ………….. textstyle, bold, italic, textcolor
    (NOTE: The order here is not important)
  2. You should also remove the “textcolor” from the list of buttons in the hideButtons property. i.e. from RTE.default.showButtons =
  3. Place the “textcolor” button in a suitable place of your preference using the toolbarOrder property.
    ex:
    RTE.default.toolbarOrder = …. space, textstyle, textcolor, …etc….
  4. Check if color picker is enabled or not, by making sure that “disableColorPicker” is set to 0
    ex:
    RTE.default.disableColorPicker = 0
  5. RTE might use the font tag to set colors, we can make sure that this does not happen by addin the font tag to the list of tags to be removed.
    ex:
    RTE.default.removeTags = font
  6. After following step 5, the font tags are no longer used for specifying font colors, hence we should make sure to set the useCSS property to true, otherwise the colors would not appear on the front-end, nor they are saved.
    ex:
    RTE.default.useCSS = 1
    (NOTE: If you wish to use font tags for text coloring thisfeature need not be set)

    Hope these steps would be helpful to you!

Additional Notes:
The above steps are sometimes just not enough and you also need to make sure that the property “[allowStyleAttribute]” is enabled in the rtehtmlarea Extension’s configuration as shown in the screenshot.

An issue Related Typo3 Update:

  • When typo3 is upgraded from 4.2 to 4.3 no matter what we do, colorpicker just does not get displayed.
    To solve this you will need to remove the rtehtmlarea config array in the localconf.php manually!
    – Just delete the line $TYPO3_CONF_VARS[‘EXT’][‘extConf’][‘rtehtmlarea’] = ……etc….
    – Go to rtehtmlarea configuration in Extension manager and click “Update” to save the new config.
    This should now make the textcolor to appear again.

Changing Menu based on selected Templavoila TemplateObject using TypoScript

TypoScript has so much features that it is indeed impossible to document each and every feature hidden with it. As we start adding extensions the feature list would increase as well.

Consider you have selected a specific Templavoila Template and you wish to have a different type of menu based on the selected template.
In such case it would be easy to change menu styles if the entire menu is enclosed in a separate CSS class.

I have given an example where I am checking for template IDs 10 , 11. If this template is used for current page I am changing it’s class.

lib.mymenu = HMENU
lib.mymenu {
entryLevel = 1
stdWrap.ifEmpty.wrap =  

1 = TMENU
1 {
wrap = <ul>|</ul>
NO.wrapItemAndSub = |</li>
NO.allWrap = <li>|
NO.allWrap {
override = <li class=”alternate_menu”>|
override.if.value = 10,11
override.if.isInList.field = tx_templavoila_to
}
# same way we can configure ACT and CUR as well
ACT = 1
CUR = 1

}

# For second level I would like to change the class of the A Tag
2 < .1
2.wrap = <ul>|</ul>
2.CUR.ATagParams = id=”cur_menu”
2.ACT.ATagParams.cObject = TEXT
2.ACT.ATagParams.cObject {
override = class=”cur_menu_a”
override.if.value = 10,11
override.if.isInList.field = tx_templavoila_to
}
3 < .2

#let us generate the 3rd level only if the page uses the Template of our choice.
3.if {
value = 10,11
isInList.field = tx_templavoila_to
}

}

Not all templates may have a template ID specified, in such case we need to use the sliding feature.
When we use the sliding feature the template id of parent ID is used.
We can do this Like:

isInList.data = levelfield:-1, tx_templavoila_to, slide

Note:
Usually Templates are stored in the Storage Folder, and you can view the Template IDs of Templavoila Template Objects from the list view!

Blunders due to auto generated content

Recently I was going through Dmitry’s twitter entries, and I suddenly came across a blog titled “The (Often Amusing) Pitfalls of Auto-Generated Content” and I was really amused about the kind of Ads Google made by combining different keywords.

The same day ironically while I was searching for something I ended up in a Google news page here:
http://www.google.com/archivesearch?q=typo3&btnG=Search+Archives&scoring=t

imageimage image

This literally made me believe that Typo3 CMS is aged over 400 years!

I checked out the three news items listed in year 1605, and it seems like Google considers all numbers with four number digit as year! Well if anyone wants to prove that their company has over 500 year old history, here is an opportunity for you 😉

This is another cool instance of a bad program logic or probably not!