dont copy files to uploads/pics/ in TYPO3

there are some reasons why TYPO3 copies every file into the well known uploads/pics/ folder that you “reference” in the backend in content elements. after copying the file there, it´s (ordinarily) protected from being deleted by the newb user or changes. if the editors changes stuff, the file is copied again after save with the _01 appendix. that leads to a bunch of issues like orphan files. theres some solution for that, but it is best to prevent that for good — if you like.

$TCA['tt_content']['columns']['image']['config']['internal_type'] = 'file';

that put into extTables.php or so sets that the file is used as is. the file is linked to where the user did upload it and no file reference is created.

use php5-xcache

if you run ordinary setups for php think about using the xcache opcode cache. it will make your TYPO3 backend and frontend faster.

while this knowledge is wide spread, i´d like to express my feelings about a very responsive t3 backend after giving more meat to the xcache size. put 80Ms there. xcache comes with a nice admin log which shows the cache hits and misses, here are the explanations.

the t3 backend (the newer the better) is lightning fast even on larger installations (hundreds of editors) due to high cache count of necessary php files. uhm, and before i forget: of course the database server must be cool, too — or you will wait for the queries to be finished and thus all the php engine speed would idle around.

piwik archive.sh out of memory

if you happen to run into memory issues piwik/core/DataTable.php with the archive.sh script of piwik you might go to free up memory on the server, like i did. memory problems with the archive script are known.

since php5/cli/php.ini shows memory_limit=-1 which means no mem limit (which i thought is a good value), i didn´t care too much about this. but at the end it turns out, a little add (-d memory_limit=1024M) to the archive shell script worked things out for me:


// snip---
echo "Archiving period = $period for idsite = $idsite..."
 CMD="$PHP_BIN -d memory_limit=1024M -q $PIWIK_PATH -- module=API&method=VisitsSummary.getVisits&idSite=$idsite&period=$period&date=last52&format=xml&token_auth=$TOKEN_AUTH"
 $CMD
// snap---

this made finally happen to bypass the archiving process for month/year and the server now has lower memory footprint because i tuned stuff down as much as i could before that :)

so, if you want to override an ini setting for the script you´re calling, the -d flag is the one to help.

tt_news and the t3lib_SpriteManager

as of TYPO3 4.4 the SpriteManager appeared, tt_news (3.0.1) starts creating lines in the deprecated log. it´s one line changed in tt_news´ ext_tables.php file.

$ICON_TYPES['news'] = array('icon' => t3lib_extMgm::extRelPath($_EXTKEY).'res/gfx/ext_icon_ttnews_folder.gif');

must be changed to:

t3lib_SpriteManager::addTcaTypeIcon('pages', 'contains-news', '../typo3conf/ext/tt_news/res/gfx/ext_icon_ttnews_folder.gif');

this is obviously part of the deprecation message thus a no-brainer. but this way you can avoid even the first appearance of this message o.O

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.

t3 version 4.4alpha backend without css and js

just solved another mystery that was dazzling my mind on a small project regarding TYPO3 version 4.4 alpha2 where the frontend worked like expected but the project code (that was updated from version 4.2.6) showed an ugly distorted backend.

all styles and javascript functions were gone!

i cleared any temporary data collection, checked rewrites, paths, everything was ok. i reloaded the sources :-) but it did not change anything. but when i started to delete all those extension corpses in typo3conf/ext/ i got one idea. extension pmktextarea integrated okay in backend in former t3 installations… and as i saw, it still did and somehow seemed to overwrite essential js for the backend. deleted the folder, cleared the TEMP* files in typo3conf/ and reloaded the backend. worked. phewww…

typo3 update to 4.3.3

all systems nominal. TYPO3 is now available in version 4.3.3 and it was easy to update for all of the projects i´m responsible for that where on 4.3.x already. good work, coredevs! looking forward to meet you at the t3dd

the changelog can be found in the TYPO3 wiki. the source can be found on sf.

my systems run without any changes. so just put the symlink to the right directory and the system is safe once more.

why update anyway?

you may delay ignore update, if following conditions are met.

  1. If you use TYPO3 in version  4.3.0, 4.3.1 or 4.3.2 (+ development releases of 4.4 branch).
  2. at least one of following PHP configuration variables set to “off”:
    • register_globals (“off” by default, advised to be “off”),
    • allow_url_include (“off” by default)
    • allow_url_fopen (“on” by default)
  3. You are using Suhosin and haven’t put URL schemes in configuration variable ”suhosin.executor.include.whitelist”.

these details were taken from the current security bulletin. TYPO3 is also a that good cms because the security team does their job that good.