Typo3-Seite geht nicht mehr

Hallo 2holden,

also für die richtigen Links in den Menüs bzw. Unterseiten habe ich nicht spezielles gemacht.
Das ging gleich mit dem Workaround beim Setzen der Variable ("$_SERVER[‘ORIG_SCRIPT_FILENAME’] = $_SERVER[‘SCRIPT_FILENAME’];"). Allerdings hatte ich anfangs nen copy&paste -Fehler und er hat mir die ursprüngliche Fehlermeldung geschickt (siehe 1. Posteintrag). Probier es mal auch nochmal neu einzufügen. Ich häng dir mal noch n Auszug aus meiner index.php an. Evtl. stehts bei dir auch an der falschen Stelle. Bei mir ists gleich nachm Copyright. ->

[code]* This copyright notice MUST APPEAR in all copies of the script!
*************************************************************/
/

  • This is the MAIN DOCUMENT of the TypoScript driven standard front-end (from the “cms” extension)
  • Basically this is the “index.php” script which all requests for TYPO3 delivered pages goes to in the frontend (the website)
  • $Id: index.php 3439 2008-03-16 19:16:51Z flyguide $
  • @author René Fritz r.fritz@colorcube.de
  • @package TYPO3
  • @subpackage tslib
    */

$_SERVER[‘ORIG_SCRIPT_FILENAME’] = $_SERVER[‘SCRIPT_FILENAME’];

// *******************************
// Set error reporting
// *******************************

error_reporting (E_ALL ^ E_NOTICE);

// ******************
// Constants defined
// ******************

define(‘PATH_thisScript’,str_replace(’//’,’/’, str_replace(’\’,’/’, (php_sapi_name()==‘cgi’||php_sapi_name()==‘isapi’ ||php_sapi_name()==‘cgi-fcgi’)&&($_SERVER[‘ORIG_PATH_TRANSLATED’]?$_SERVER[‘ORIG_PATH_TRANSLATED’]:$_SERVER[‘PATH_TRANSLATED’])? ($_SERVER[‘ORIG_PATH_TRANSLATED’]?$_SERVER[‘ORIG_PATH_TRANSLATED’]:$_SERVER[‘PATH_TRANSLATED’]):($_SERVER[‘ORIG_SCRIPT_FILENAME’]?$_SERVER[‘ORIG_SCRIPT_FILENAME’]:$_SERVER[‘SCRIPT_FILENAME’]))));

define(‘PATH_site’, dirname(PATH_thisScript).’/’);[/code]

Im square7-Forum wird behauptet das für typolight dieser Workaround helfen soll:

$_SERVER[‘ORIG_SCRIPT_NAME’] = $_SERVER[‘SCRIPT_NAME’];

Vielleicht probierst den bzw. beide mal aus. Evtl. klappts ja auch im typo3.

Ja, das square7 Forum hab ich auch im Blick. Bringt mich aber auch nicht weiter.

Bei mir sitzt die Definition an genau derselben Stelle.

Hast Du den tslib/ Pfad angegeben? Vorher war der ja leer. also ’ ’ .

[quote]// define path to tslib/ here:
$configured_tslib_path = ‘/users/dangast/www/typo3/sysext/cms/tslib/’;[/quote]

Und noch was: Kommst Du jetzt in Dein Backend rein?

Danke!

Hallo grasfresser und alle anderen,
die Hinweise mit der path config und dem Zusatz oben in der index.php führen bei dazu, daß die Seite wieder aufrufbar ist. Vielen Dank.
Allerdings komm ich noch nicht ins backend- hat dafür jemand eine Lösung?
Gruß
peter

Also ich hab ja, wie an anderer Stelle gepostet, auch das gleiche Problem und steh genauso auf dem Schlauch. Aber ich denke, wie Miro, dass es ein grundsätzliches Problem in Typo3 gibt. Die falschen Links hängen meiner Meinung nach damit zusammen, dass Typo generell das Systemverzeichnis für temporäre Dateien benutzt (binary-exec, binary, core …), die sind hier bei bplaced aber sinnvollerweise für unseren Zugriff gesperrt. (korrigiert mich bitte, wenn ich das falsch verstehe). Ein Sicherheitslücke in PHP hat es bisher möglich gemacht, dass mit tempnam() doch in diesen Systemverzeichnissen des Servers zwischengespeichert worden ist, wenn nicht explizit ein eigenes Temp-Verzeichnis angegeben worden ist. Diese Lücke ist jetzt aber geschlossen und Typo3 bleibt wohl an solchen Stellen, wo temporäre Daten benutzt werden immer hängen.

In der class.t3lib_div.php im t3lib-Verzeichnis finden sich die beiden folgenden Funktionen:

	/**
	 * Deletes (unlink) a temporary filename in 'PATH_site."typo3temp/"' given as input.
	 * The function will check that the file exists, is in PATH_site."typo3temp/" and does not contain back-spaces ("../") so it should be pretty safe.
	 * Use this after upload_to_tempfile() or tempnam() from this class!
	 * Usage: 9
	 *
	 * @param	string		Filepath for a file in PATH_site."typo3temp/". Must be absolute.
	 * @return	boolean		Returns true if the file was unlink()'ed
	 * @see upload_to_tempfile(), tempnam()
	 */
	public static function unlink_tempfile($uploadedTempFileName)	{
		if ($uploadedTempFileName && t3lib_div::validPathStr($uploadedTempFileName) && t3lib_div::isFirstPartOfStr($uploadedTempFileName,PATH_site.'typo3temp/') && @is_file($uploadedTempFileName))	{
			if (unlink($uploadedTempFileName))	return TRUE;
		}
	}

	/**
	 * Create temporary filename (Create file with unique file name)
	 * This function should be used for getting temporary filenames - will make your applications safe for open_basedir = on
	 * REMEMBER to delete the temporary files after use! This is done by t3lib_div::unlink_tempfile()
	 * Usage: 7
	 *
	 * @param	string		Prefix to temp file (which will have no extension btw)
	 * @return	string		result from PHP function tempnam() with PATH_site.'typo3temp/' set for temp path.
	 * @see unlink_tempfile(), upload_to_tempfile()
	 */
	public static function tempnam($filePrefix)	{
		return tempnam(PATH_site.'typo3temp/',$filePrefix);
	}

Eigentlich denke ich, dass hiermit generell auf das typo3temp-Verzeichnis umgelenkt werden soll. Aber das scheint nicht zu funktionieren und hier bin ich auch mit meinem Latein am Ende.

Das Einfügen von $_SERVER[‘ORIG_SCRIPT_FILENAME’] = $_SERVER[‘SCRIPT_FILENAME’]; bringt nur oberflächliche Erleichterung. Ihr könnt das z.B. auch mal in die init.php im Typo3-Verzeichnis einfügen. Dann kommt man ins Backend, aber da taucht dann schon das nächste Problem auf. Das ist ein unendlicher Rattenschwanz. Und bei jedem Update geht das wieder von vorne los. Zum Teil betrifft das auch die Extensions. Und auch die Definition von $configured_tslib_path ist nur ein Rumdoktern an der Oberfläche.

Also postet das Problem bitte mal in den einschlägigen Typo3-Foren (z.B. typo3forum.net/). Ich hab da im Moment eigentlich überhaupt nicht die Zeit dafür. Da muss eine generelle Lösung gefunden werden, von Leuten, die sich mit Typo3 und PHP auskennen. Da die meisten Typo3-Installationen allerdings nicht bei Freehostern und unter PHP 5.3.2 laufen, gehören wir zu einer Minderheit, die überhaupt dieses Problem zur Zeit hat.

Vermutlich gibt es PATH_site.‘typo3temp/’ nicht und deshalb wird auf den Standart-Temp-Ordner zurückgegriffen, was man wohl nicht darf.
Hat mal jemand geguckt was in PATH_site steht? Wahrscheinlich hängt das mit dem Workaround zusammen und in PATH_site steht irgendwas falsches drin. Das könnte man als weiteres Workaround ja hardcoden (also den richtigen Path an dieser Stelle).

Kann das leider nicht testen, weil ich keine Typo3-Installation mehr auf bplaced hab.

Hallo,
ich komm also nicht ins Backend. Wenn ich Preck glaube, gibt es für typo3 dann keine Möglichkeit bplaced zu nutzen???
Wenn mein CMS nicht administrieren kann, brauch ich auch keines. Vielleicht hat noch irgendjemand eine Lösung parat.
PS: Mit dem Zusatz in der init.php komme ich wirklich auf das Typo3 login - aber das wars dann auch.
Gruß
peter

@Preck

typo3.net/forum/list/list_post//97396/

Da steht es schon eine Weile herum. Interessiert aber keinen, bzw. es weiß keiner eine Antwort.

[quote=“2holdon”]
Hast Du den tslib/ Pfad angegeben? Vorher war der ja leer. also ’ ’ .

// define path to tslib/ here:
$configured_tslib_path = ‘/users/dangast/www/typo3/sysext/cms/tslib/’;[/quote]
Nein hab ich nicht, hab es wieder auskommentiert:

// define path to tslib/ here: //$configured_tslib_path = '/users/grasfresser/www/typo3/sysext/cms/tslib/'; //$configured_tslib_path = '';

[quote=“2holdon”]
Und noch was: Kommst Du jetzt in Dein Backend rein?[/quote]
Nein leider auch nicht, nur auf die Login-Seite. Bei mir kommt auch die url mit “binary-exec” drin.

Noch was anderes, habt ihr auch die ganzen Warnings/Fehlermeldungen auf eurer Startseite? Bei manchen Menüseiten sind es noch mehr.

[color=#BF0000]Deprecated: Function ereg_replace() is deprecated in /users/grasfresser/www/t3lib/class.t3lib_page.php on line 499

Deprecated: Function ereg_replace() is deprecated in /users/grasfresser/www/t3lib/class.t3lib_page.php on line 501

Deprecated: Function ereg_replace() is deprecated in /users/grasfresser/www/t3lib/class.t3lib_page.php on line 504

Warning: Cannot modify header information - headers already sent by (output started at /users/grasfresser/www/t3lib/class.t3lib_page.php:499) in /users/grasfresser/www/typo3conf/ext/pp_stats/class.tx_ppstats_tsfehook.php on line 114

Deprecated: Function ereg() is deprecated in /users/grasfresser/www/typo3conf/ext/pp_stats/class.tx_ppstats_tsfehook.php on line 163

Warning: Cannot modify header information - headers already sent by (output started at /users/grasfresser/www/t3lib/class.t3lib_page.php:499) in /users/grasfresser/www/typo3/sysext/cms/tslib/class.tslib_fe.php on line 3229[/color]

Deprecated heißt aber ganz klar, dass die verwendete Funktion veraltet ist, mit der nächsten großen PHP Version wird es ganz abgeschafft. Also hier müssten die Typo3 Entwickler wirklich mal dran arbeiten…

@grasfresser
Bei mir kommt die Seite ohne jegliche Fehlermeldung und auch die Menuepunkte lassen sich einwandfrei aufrufen. www.gospelchor.bplaced.net
Zum Backend
Ersetze ich nach login das binary durch typo3, dann bin ich im Backend, will ich aber dann dort das Seitenmenue aufrufen kommt die Fehlermeldung von bplaced “keine Berechtigung”.
Peter

Danke für den Tip gospelchor. Allerdings funktioniert es bei mir nicht. Wenn ich statt binary-exec typo3 eingebe erscheint bei mir eine Typo3-Login-Session-Error Meldung:

[color=#4040BF]Login-error or session timed-out

No user logged in! Sorry, I can’t proceed then!

(You must have cookies enabled!)

If your session has just timed-out, you may
click here to re-login.[/color]

Ganz links oben wird noch ein Pfadname angezeigt. ->
/users/grasfresser/www/typo3/TYPO3_MOD_PATHtypo3/

Evtl. liegt das an unterschiedlichen Typo3-Versionen? Welche hast du drauf? Bei mir ist es die 4.2. Ist ja auch seltsam das bei mir die ganzen warnings angezeigt werden.

hi,

… hat sich schon mal jemand an den Typo-Support gewendet?
Ihr diskutiert hier über einen Fehler, der seitens Typo zu korrigieren ist.

ciao

Es funktioniert wieder alles bis auf das Backend.

Und das nachdem ich mir gerade eine Notlösung gebastelt hatte. Na, wer weiß wann ich die mal wieder brauche. !coffee

Tatsächlich hatte ich irgendwann mal probiert die Extension RealUrl zu installieren. Das hat aber nicht geklappt, daher hab ich sie einfach deaktiviert. Nicht genug offensichtlich. Denn nachdem ich sie mit dieser Anleitung (http://www.fladi.de/2008/07/24/howto-typo3-extension-manuell-ohne-backend-loeschen/) entfernt habe, die Definition reingetan habe und den Pfad in der tslib leergelassen habe, funktioniert nun wieder zumindest das Frontend wie gewünscht.

Edit: Damit miro auch zufrieden ist und wir wenigstens alles probiert haben, habe ich eine email an typo3.com/Contact.1359.0.html) geschrieben. Vielleicht kommt ja eine Antwort. :wink:

Das mit der email finde ich sehr gut. Ich habe das Problem auch bei typo3.net forum reingestellt, allerdings war bisher die einzige Antwort: Such Dir einen Hoster, wo´s funktioniert. Naja
Hoffe ich erfahre neues hier oder dort
Peter

hola,

schöne Antwort. Statt sich um die Programmierung zu kümmern, einfach sowas antworten … naja, jeder, der PHP 5.3 einsetz, wird wohl auf 5.3.2 umstellen oder es schon getan haben, womit das Problem dann häufiger auftreten wird. Unfassbar eigentlich, dass man solche Antworten präsentiert bekommt.

ciao

Auf den Typo3-Support würde ich eher nicht warten wollen. Ich denke wir müssen uns da schon selbst reinknien, wenn wir das bald wieder zum Laufen kriegen wollen.

@grasfresser
Deine Fehlermeldungen tauchen bei mir nicht auf, obwohl ich auch 4.2 drauf hab. Mag sein, dass das von irgend einer Extension bei dir benutzt wird.

@Umpalumpa
Deinen Ansatz finde ich gut. Da werde mich mich mal weiter mit auseinandersetzen. In der index.php wird PATH-site definiert:

define('PATH_thisScript',str_replace('//','/', str_replace('\\','/', (php_sapi_name()=='cgi'||php_sapi_name()=='isapi' ||php_sapi_name()=='cgi-fcgi')&&($_SERVER['ORIG_PATH_TRANSLATED']?$_SERVER['ORIG_PATH_TRANSLATED']:$_SERVER['PATH_TRANSLATED'])? ($_SERVER['ORIG_PATH_TRANSLATED']?$_SERVER['ORIG_PATH_TRANSLATED']:$_SERVER['PATH_TRANSLATED']):($_SERVER['ORIG_SCRIPT_FILENAME']?$_SERVER['ORIG_SCRIPT_FILENAME']:$_SERVER['SCRIPT_FILENAME']))));

define('PATH_site', dirname(PATH_thisScript).'/');

[quote=“Preck”]
@Umpalumpa
Deinen Ansatz finde ich gut. Da werde mich mich mal weiter mit auseinandersetzen. In der index.php wird PATH-site definiert:

[code]
define(‘PATH_thisScript’,str_replace(’//’,’/’, str_replace(’\’,’/’, (php_sapi_name()==‘cgi’||php_sapi_name()==‘isapi’ ||php_sapi_name()==‘cgi-fcgi’)&&($_SERVER[‘ORIG_PATH_TRANSLATED’]?$_SERVER[‘ORIG_PATH_TRANSLATED’]:$_SERVER[‘PATH_TRANSLATED’])? ($_SERVER[‘ORIG_PATH_TRANSLATED’]?$_SERVER[‘ORIG_PATH_TRANSLATED’]:$_SERVER[‘PATH_TRANSLATED’]):($_SERVER[‘ORIG_SCRIPT_FILENAME’]?$_SERVER[‘ORIG_SCRIPT_FILENAME’]:$_SERVER[‘SCRIPT_FILENAME’]))));

define(‘PATH_site’, dirname(PATH_thisScript).’/’);
[/code][/quote]

ok also wenn man das mal auseinanderklamüsert, dann heißt das ja soviel wie:
wenn php_sapi_name() gleich cgi, isapi oder cgi-fcgi ist und es $_SERVER[‘ORIG_PATH_TRANSLATED’] oder $_SERVER[‘PATH_TRANSLATED’] gibt ist:
PATH_site = $_SERVER[‘ORIG_PATH_TRANSLATED’] bzw $_SERVER[‘PATH_TRANSLATED’]

und ansonsten ist:
PATH_site = $_SERVER[‘ORIG_SCRIPT_FILENAME’] bzw $_SERVER[‘SCRIPT_FILENAME’]

setzt man jetzt noch durch den workaroung die origs gleich die normalen also:
$_SERVER[‘ORIG_SCRIPT_FILENAME’] = $_SERVER[‘SCRIPT_FILENAME’]
$_SERVER[‘ORIG_PATH_TRANSLATED’] = $_SERVER[‘PATH_TRANSLATED’]
ist PATH_site ja schonmal entweder
$_SERVER[‘PATH_TRANSLATED’] oder $_SERVER[‘SCRIPT_FILENAME’]

damit müsste man ja jetzt gucken können was für den path von tempnam() rauskommt und ob es den gibt. Das müsste mal jemand von euch rausfinden, der das testen kann.

Also was ich jetzt erstmal rausgefunden habe:

PATH_site enthält ohne den Workaround den Wert “/users/bplacedname/core/” und das ist natürlich murks! Mit Workaround ist es “/users/bplacedname/www/typo3verzeichnis/”

Und $_SERVER[‘ORIG_SCRIPT_FILENAME’] enthält “/users/bplacedname/core/php”.

Was ist das denn eigentlich für eine Servervariable? Ich hab da spontan nichts drüber gefunden.

[quote=“Preck”]Und $_SERVER[‘ORIG_SCRIPT_FILENAME’] enthält “/users/bplacedname/core/php”.

Was ist das denn eigentlich für eine Servervariable? Ich hab da spontan nichts drüber gefunden.[/quote]

OK das macht soweit sinn, als dass dirname() aus “/users/bplacedname/core/php” “/users/bplacedname/core/” macht. Das is ja auch das was ohne Workaround rauskommt.

$_SERVER[‘SCRIPT_FILENAME’] gibt ja eigentlich immer den Pfad zum aktuellen Script aus.
was $_SERVER[‘ORIG_SCRIPT_FILENAME’] ist, versteh ich auch nicht. Wenn man danach googled bekommt man erstmal nur diesen Thread und Typo3-Krams…

Funktioniert das denn mit Workaround? also ist der Pfrad, der da rauskommt, der richtige?
Dann würd ich einfach sagen Typo3 nutzt da aus irgend einem Grund die falsche ORIG_ Variable und sollte eigentlich die normale nutzen…

Ich versteh auch den Sinn der ORIG_-Variablen nicht. Auf nem anderen Server von mit ist in
$_SERVER[‘SCRIPT_FILENAME’] "/home/www/user/html/sonstiges/phpinfo.php"
und in $_SERVER[‘ORIG_SCRIPT_FILENAME’] "/home/www/user/html/cgi-bin/php-fcgi-starter"
also was komplett anderes. Scheint aber wohl irgendwas mit cgi-bin zutun zu haben… (zumal das ja auch in dem Typo3-code abgefragt wird…)

Vielleicht kann ja irgendwer sonst was damit anfangen…