[TYPO3] Meta extract for DAM

Xavier Perseguers typo3 at perseguers.ch
Wed Apr 16 14:40:10 CEST 2008


Hi there,

I posted this question to the DAM list and finally decided to track this 
problem down, wherever it would get me and... yes! I got the answer:

1) I use openbase_dir restrictions in php.ini and I forgot to include in 
the list my special directory holding binaries TYPO3 is allowed to 
execute (not the standard /usr/bin/). As the is_dir() function is used 
to check for invalid paths in t3lib/class.t3lib_exec.php, I got a 
"openbase_dir exception" that leaded to invalidate my special bin 
directory as a valid directory to be searched for external tools

2) My TYPO3 binary directory is a set of external tools such as 
pdftotext, exiftags, unzip, ... that are *symbolic links* to the real 
executable that mostly rely in /usr/bin. Problem is that 
t3lib/class.t3lib_exec.php tries to find out if the configured tool is 
executable, leading to invalidate any symbolic link to /usr/bin as 
openbase_dir restriction is again in action.

My conclusion is as follows:

1) the tests in both classes I described above and located in t3lib_dir 
do checks using the "@" prefix to functions is_dir() and 
is_executable(). That is any warning (such as the openbase_dir 
restriction) will not be put in the PHP error log. I think this is a 
problem that should be tackled with as it is complicated to track down 
such issues.

2) A better check should be used as openbase_dir just works fine with 
the same external tools when used in extensions such as indexed_search.

3) I cannot hard link to these tools as my web space is stored on 
another disk partition and whenever I choose to copy those external 
tools to my dedicated bin directory, I'll have to manually take care of 
any update to them.

May I contribute to enhance this base class? Do someone disagree with my 
point of view? And if so, why?


More information about the TYPO3-english mailing list