PHP FastCGI mit suPHP und rewrite (.htacces)

[twisterchen]

Hallo

Also irgendwie steh ich gerade auf dem schlauch aber, wenn ich einen XTC mit mod_PHP lauffen habe funktionierten die Suchmaschinenfreundlichen URLS einwandfrei stelle ich den Shop auf PHP FastCGI mit suPHP um funktionieren die SMFL nicht mehr.

Jetzt frag ich mich was das mit PHP zu tun hat das ist doch ein eigenes Apachemodul mod_rewrite.

WO liegt denn jetzt mein Denkfehler oder was könnt ihr mir für einen TIP geben

Gruss
Twisterchen

[dtdesign]

Wieso benutzt du FastCGI mit suPHP? Was ist das denn für eine Logik?

Zu deinem Problem: Du musst einen Schalter anstellen, damit der Webserver gegenüber dem PHP auf CGI-Basis geschwätziger wird. Frag mich aber bitte nicht welchen, ich hab mich gerade zu Tode gesucht.

Gehen tut es auf jeden Fall.

[twisterchen]

Wieso benutzt du FastCGI mit suPHP? Was ist das denn für eine Logik?

Was gibts den daran auszusetzen ?

Mit dem Stichwort Schalter kann ich leider nichts anfangen ! Schalter gibt es im Apachen viele.

Noch jemand einen Tip

[r. u. serious]

stelle ich den Shop auf PHP FastCGI mit suPHP um funktionieren die SMFL nicht mehr.

"Funktioniert nicht" ist keine Fehlerbeschreibung, sondern eine Kapitulation. Was machst du, was erwartest du und was passiert stattdessen? HTTP-Fehlercode - 404, 500, 503? Oder ein 200 und nur die falsche Seite wird angezeigt? Ist die Fehlerseite die des Apaches, oder bekommt die Shop-Anwendung noch den Request und produziert selber eine Fehlermeldung? Hat der Shop eine Art "front-controller", welche die entsprechenden views generiert - oder werden die verschiedneen Requests allein von mod_rewrite auf verschiedene PHP-Skripte weitergeleitet/umgeschrieben?

[twisterchen]

Also in der htaccess stehen keine rewrite anweisungen drinnen, man kann im Backend vom XTC die Einstellung "Suchmaschienenfreundliche URLs" verwenden.

In der htaccess steht eigentlich gar nichts drinnen funktionieren tut es aber mit mod_PHP mit FastCGI nicht.

Fehlerseiten gibt es keine der Shop wird nur dann immer mit der Startseite angezeigt egal welche(n) Kategorie oder Link ich anklicke der zu einem Artikel führt.

"front-controller" ich denke mal ja da keine Requests in htaccess vorhanden sind und mit mod_PHP funktionieren.

[r. u. serious]

Dann verläßt sich sich die Shop-Anwendung auf bestimmte gesetzte Variablen in $_SERVER o.ä.. KLassisches Beispiel zum prüfen wäre "REQUEST_URI" - kann sein dass die variable mit fcgi bei dir nicht gesetz wird. Da gibt es aber zahlreiche Workarounds mit SCRIPT_NAME+QUERY_STRING, oder argv usw.

[twisterchen]

Das dürfte ja dann nur eine PHP.ini Einstellung sein !!! ?

[twisterchen]

Also irgendwie komm ich hier mit meiner Denkensweise nicht weiter, das ganze ist doch nur ein PHP Problem den ander Apache Conf kanns nicht liegen sonst würde es ja nicht mit mod_PHP funktionieren. {AllowOverride FileInfo AcceptPathInfo on}
http://fsinf.informatik.uni-leipzig.de/ ... ptPathInfo

Code: Select all

<?php
#phpinfo();
if (strlen(getenv('PATH_INFO')) > 1) {
   $GET_array = array();
   $PHP_SELF = str_replace(getenv('PATH_INFO'), '', $PHP_SELF);
   $vars = explode('/', substr(getenv('PATH_INFO'), 1));
   for ($i=0, $n=sizeof($vars); $i<$n; $i++) {
    if (strpos($vars[$i], '[]')) {
     $GET_array[substr($vars[$i], 0, -2)][] = $vars[$i+1];
    } else {
     $_GET[$vars[$i]] = $vars[$i+1];
    }
    $i++;
   }

   if (sizeof($GET_array) > 0) {
    while (list($key, $value) = each($GET_array)) {
     $_GET[$key] = $value;
    }
   }
  }


echo '<pre>';
print_r ($_GET);
echo '</pre>';
?>

Folgende Ausgabe müsste mir bei einem link mit info.php/aa/bb/xx/dd
ausgeben.

Code: Select all

Array
(
[aa] => bb
[xx] => dd
)

TUUUUT es aber nicht also kann es doch nur eine PHP Einstellung sein ich bin wirklich für jeden weiteren TIP Dankbar

Gruss
Twisterchen