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.

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.

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.

update current list of available plugins from TER

one step closer to TYPO3 backend convenience

scheduled update of the extension list from the TYPO3 extension repository (TER). the extension needed has the cryptic key rscliem and will provide command line interface function for extension manager operations. just import and install it.

If you have no BE-user named _cli_lowlevel go and create it. That one’s needed to run PHP CLI commands.

test the cliKey ‘emtools’

/var/www/my-t3site/typo3/cli_dispatch.phpsh emtools --update-extensionlist

It will return a fancy array containing a message like
[0] => <p>The extension list has not changed remotely, it has thus not been fetched.</p>

(at least if you run the command successfully a second time)

To have the Extension List updated twice a day, a small entry in the current cron tab comes in handy:

# m h  dom mon dow   command
00   */12    *     *     *  /var/www/my-t3site/typo3/cli_dispatch.phpsh emtools --update-extensionlist
MAILTO="adminmail@mydomain.com"

The following options can be used:

  • –update-mirrors
    Updates mirror list from typo3.org
  • –update-extensionlist
    Retrieves current extensionlist from selected mirror and load into database
  • –check-extensions
    Checks currently installed extension for newer versions
  • –import-updates
    Imports updates for all extension, found with –check-extensions.

(taken from the README file found in typo3conf/ext/rscliem/)

You see, you can possibly automate the extension update process. I currently can’t use this feature because some extensions would break the TYPO3 instance in question if updated to newest version.

But the handy part is to have the list of extensions to update emailed to me.A connection of the updated extension list and the extension chack makes most sense.

./cli_dispatch.phpsh emtools --update-extensionlist && ./cli_dispatch.phpsh emtools --check-extensions

piwik shows General error: 126

last week there was everything working fine. no changes made. today, stuff is not running fine. piwik in version 0.4.1 does not show useful content anymore. if you ever get to see all your widgets showing the General error 126″ you can start over with mysqlrepair.

General error: 126 Incorrect key file for table ‘/tmp/#sql_6d3c23.MYI’; try to repair it

SQLSTATE[HY000]

Yes sir, we’re going to repair the database totally. To do so, we fire up

mysqlrepair -B piwik -force -p

which will show a lot of OK rows. option -A is for all databases, so if your mysql server is in production and you’ve got a bunch of dbs on it hot, you propably consider using -B option to point to the single piwik database. I had to retry this with different options but now the things looks okay.

so today’s view is fixed, but since the problem existed for around three days, two days of data are corrupted. so i open config/global.ini.php and set the debugsters to 1.

[Debug]
; the archiving process will always be triggered, even if the archive has already been computed
always_archive_data_period = 1;
always_archive_data_day = 1;

; if set to 1, all the SQL queries will be recorded by the profiler
enable_sql_profiler = 1;

after having reprocessed the complete archive, which does take quite a while, there is still a report of an incorrect key file. But now with nice SQL profiling., d’oh.

<?xml version="1.0" encoding="utf-8" ?>
<result>
<error message="SQLSTATE[HY000]: General error: 126 Incorrect key file for table '/tmp/#sql_694e23.MYI'; try to repair it" />
</result>

solution

the problem was caused by a /tmp partition defined too small (16mb on a guest). now as i raised the tmpfs size the system works normal again. in vserver landscapes you can search a while before finding the corresponding fstab in /etc/vservers/yourvserver/fstab on the host. All this can be found in the vserver faq section.

Thanks to @schommr for the tip.

Best of it all, your data won’t be gone if you have a problem like this. It just can’t be processed to show correctly. My concerns about several days loss of data were flushed away when piwik’s archive.sh ran through in about twenty minutes. go piwik!

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.

piwik statistics and analytics

some of you may have noticed the Piwik link in my blog´s menu bar. well, I am using Piwik as open source website analysis tool for more projects now and it works just fine. this is why I just wanted to throw another blog post about it into the web. and here it is! Piwik is cool.

Other posts describe the pros and con of Piwik far better than I´d do in the next few minutes, that´s why I´ll tap it short:

  • MySQL & PHP – everybody should have that nowadays
  • easy installation – piece of cake if you can handle a ftp client
  • js based tracking – kind of customizable
  • excellent data export possibilities
  • it´s open source
  • you gonna own your own collected data

Speeding up things

For websites with some traffic, you´ll need quite more than the suggested minimum 128mb of memory for php. To have the Piwik interface sound and responding, you may want to precollect the tracking data with a cron job.

Generate a new user for Piwik ( piwik/index.php?module=UsersManager&action=index ) and copy the authorization token that you´ll get to paste it into the archive.sh file found under misc/cron/ in your Piwik folder.

crontab -u www-data -e

Append this line

5 0 * * * /path/to/piwik/misc/cron/archive.sh > /dev/null 

Your box will respond way faster after having processed this. This is why I can check smoothly that it stais the way it used to be: my blog is being majorly visited with uptodate browsers and merely around 10% with IE or other funny stuff. Hoorray.

$TBE_STYLES and custom css in TYPO3 backend

the most of this night went on to find out how to bring my own css file to the TYPO3 backend for my own extensions, which happen to be more and more BE modules. This is just readable fun of an oldschool try and error session.

The issue is, if you go and program stuff that makes your life in the backend more comfortable, you´d better go for it the real way. It has to look nice, at least as much as the skin of TYPO3 does itself. Speaking of this, I kinda like the way they´re going in 4.2. But I hate that the following line of code blows away all the “4.2 magic” and reveals you the historic 3.x backend interface style. Time to move on…


$TBE_STYLES['styleSheetFile_post'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

Doing so will overwrite the following commands, next to others. Imagine, how devastating this is.


@import "typo3-colors.css";
@import "typo3-alt-menu-php.css";
@import "typo3-alt-db-navframe-php.css";
@import "typo3-db-list-php.css";
@import "typo3-clipboard.css";
@import "typo3-alt-topmenu-dummy-php.css";
@import "typo3-alt-palette-php.css";
@import "typo3-TCEforms.css";
@import "typo3-dyntabmenu.css";
@import "typo3-index-php.css";
@import "typo3-tree.css";
@import "ext-cms-layout-db-layout-php.css";
@import "typo3-file-list.css";
@import "typo3-csh.css";
@import "typo3-workspaces.css";

So, THIS does not work. And don´t try this at home, it will shock you ;) You may try to reinvent another BE style at all (thus skipping on importing around 20 stylesheet files) but I am not going to do that.

Better stick on this following line in the ext_tables.php of your extension. It works for my purposes right now: it just adds a stylesheet file that comes packed with the ext when installing.

$TBE_STYLES['stylesheet2'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

Note that the css file in this case resides in the extension root folder. It works for one extension using this line of code. But if you have another one with the exact same command, there will only be one of the css files, but you might be expecting two of them. Well, how about guessing cool numbers that nobody else is going to use? (23, 42… any eleven digit prime number should work just fine)

It is understandable that the post-style is for having the important skin features included at last. That ensures that nobody else freaks out with the standard css commands for the backend. css is just so good. But how are we supposed to create a backend user experience that fits into the style, but with a touch of our own unique taste? It´s just humiliating to produce hardcoded html style attributes. ^^

Custom CSS, just include it

I ran into this problem this night, because I am developing two BE modules simultaneously, that can´t be fusioned to one in a semantic matter. Both should have got the css fanciness, but only the stylesheet2 field in $TBE_STYLES can be used safely. So is my experience to date.

The perfect solution would be the associative array at $TBE_STYLES['stylesheet']. Note the missing 2. I thought, it was clever to just extend this array to my needs like in the following code. Unfortunately, it didn´t work as expected.

$TBE_STYLES['stylesheet']['bbb_sortwizard'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

This would make every extension that needs a css file loaded to save it using the extension´s unique key. But, it did not work out. Two fields are predefined:

[modulemenu]=sysext/t3skin/stylesheets/modulemenu.css
[backend-style]=sysext/t3skin/stylesheets/backend-style.css

A good point to start on drilling the holes into the core, eh? ^^

Tonight, I rather used the quicker solution that will work in a way:

Putting the css inline

$TBE_STYLES['inDocStyles_TBEstyle'] .= '
.someclass {margin-top: 10px;}
.anotherclass {border: 1px solid black;}';

See the nasty concatenation of this value. It is naive to think that this is the best possible way to bring in own style to the backend of TYPO3. Well, the conclusion is, as long the internet does not present me more information on that issue (tell me how to do it in a constructive comment, this is appreciated) I will stick to the last mentioned way of inline css.

If you do as well, please concatenate too, that if you happen to be the last extension to be loaded, the code of the other extensions are respected, too. “Older” css commands otherwise would be deleted. Thank you.