Caretaker

Hi,

after updating both the caretaker-extension (to rev 48208) and TYPO3 (to 4.5.3) the "TYPO3 Versionnumbers Update"-task now fails with a different error:
Execution failed: 0, String could not be parsed as XML

The field lastexecution_failure of table tx_scheduler_task contains this error-message:
O:9:"Exception":6:{s:10:"*?message";s:33:"String could not be parsed as XML";s:17:"Exception?string";s:0:"";s:7:"*?code";i:0;s:7:"*?file";s:112:"/srv/www/htdocs/t3_caretaker/typo3conf/ext/caretaker/classes/helpers/class.tx_caretaker_LatestVersionsHelper.php";s:7:"*?line";i:60;s:16:"Exception?trace";a:5:{i:0;a:6:{s:4:"file";s:112:"/srv/www/htdocs/t3_caretaker/typo3conf/ext/caretaker/classes/helpers/class.tx_caretaker_LatestVersionsHelper.php";s:4:"line";i:60;s:8:"function";s:11:"__construct";s:5:"class";s:16:"SimpleXMLElement";s:4:"type";s:2:"->";s:4:"args";a:1:{i:0;s:0:"";}}i:1;a:6:{s:4:"file";s:115:"/srv/www/htdocs/t3_caretaker/typo3conf/ext/caretaker/scheduler/class.tx_caretaker_typo3versionnumbersupdatetask.php";s:4:"line";i:50;s:8:"function";s:32:"updateLatestTypo3VersionRegistry";s:5:"class";s:33:"tx_caretaker_LatestVersionsHelper";s:4:"type";s:2:"::";s:4:"args";a:0:{}}i:2;a:6:{s:4:"file";s:75:"/srv/www/libs/typo3_src-4.5.3/typo3/sysext/scheduler/class.tx_scheduler.php";s:4:"line";i:176;s:8:"function";s:7:"execute";s:5:"class";s:42:"tx_caretaker_Typo3versionnumbersupdateTask";s:4:"type";s:2:"->";s:4:"args";a:0:{}}i:3;a:6:{s:4:"file";s:83:"/srv/www/libs/typo3_src-4.5.3/typo3/sysext/scheduler/cli/scheduler_cli_dispatch.php";s:4:"line";i:53;s:8:"function";s:11:"executeTask";s:5:"class";s:12:"tx_scheduler";s:4:"type";s:2:"->";s:4:"args";a:1:{i:0;O:42:"tx_caretaker_Typo3versionnumbersupdateTask":5:{s:10:"*?taskUid";i:2;s:11:"*?disabled";b:0;s:12:"*?execution";O:22:"tx_scheduler_Execution":6:{s:8:"*?start";i:1307628000;s:6:"*?end";s:0:"";s:11:"*?interval";i:86400;s:11:"*?multiple";s:1:"0";s:10:"*?cronCmd";s:0:"";s:23:"*?isNewSingleExecution";b:0;}s:16:"*?executionTime";i:1307714400;s:12:"*?scheduler";O:12:"tx_scheduler":1:{s:7:"extConf";a:1:{s:11:"maxLifetime";i:1440;}}}}}i:4;a:4:{s:4:"file";s:54:"/srv/www/libs/typo3_src-4.5.3/typo3/cli_dispatch.phpsh";s:4:"line";i:123;s:4:"args";a:1:{i:0;s:83:"/srv/www/libs/typo3_src-4.5.3/typo3/sysext/scheduler/cli/scheduler_cli_dispatch.php";}s:8:"function";s:7:"include";}}}

The error only occurs if the task is excuted automatically by the scheduler but not if I start it manually using the "Execute selected tasks"-button in the scheduler-module.

I think the problem is that the server (Suse Linux) is located behind a proxy. Obviously curl isn't using the proxy if the script is called by the scheduler automatically. The "typo3/cli_dispatch.phpsh scheduler"-command is scheduled in the crontab of the user wwwrun, which is the same who is running the webserver (apache). After adding this line in caretaker/classes/helpers/class.tx_caretaker_LatestVersionsHelper.php (line 91) the task runs fine:
curl_setopt($curl, CURLOPT_PROXY, "webproxy:8080");

In curl-documentation (http://curl.haxx.se/libcurl/c/libcurl-tutorial.html) it says:
Environment Variables
libcurl automatically checks and uses a set of environment variables to know what proxies to use for certain protocols. The names of the variables are following an ancient de facto standard and are built up as "[protocol]_proxy" (note the lower casing). Which makes the variable 'http_proxy' checked for a name of a proxy to use when the input URL is HTTP.

Using the export-command I can see that the following environment variables are actually set:
declare -x ftp_proxy="http://webproxy:8080/"
declare -x http_proxy="http://webproxy:8080/"
declare -x https_proxy="http://webproxy:8080/"
declare -x no_proxy="localhost, 127.0.0.1, bs.ptb.de"

I've no idea why curl is ignoring these environment variables.

Cheers, Tobias

I refactored the tx_caretaker_LatestVersionsHelper in my caretaker fork on Github: https://github.com/etobi/caretaker
It now uses the official JSON releases feed at get.typo3.org/json and should be much more staple.

Could you test if this issue is solved with that version? If yes, i can "pull request" it into the official repository.

I tested your fork from Github and could not reproduce the error.