[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