URL-Umschreibung ohne Suffix

**arnoldB** · 02.04.2010, 18:52

Hallo,

leider funktioniert die URL-Umschreibung auf der Website www.laurentiusweb.de nicht. Nach der Aktivierung dieser Funktion meldet Server 404 Error.

Der Inhalt der .htaccess Datei:

Code:

##
# Rewrite base
##
RewriteEngine On
RewriteBase /

##
# Block malicious requests
##
RewriteCond %{REQUEST_URI} (ftp|https?):|/etc/ [NC,OR]
RewriteCond %{QUERY_STRING} (ftp|https?):|/etc/ [NC]
RewriteRule .* - [F,L]

##
# Compress .js and .css files
##
AddEncoding gzip .gz
<FilesMatch "\.js\.gz$">
  AddType "text/javascript" .gz
</FilesMatch>
<FilesMatch "\.css\.gz$">
  AddType "text/css" .gz
</FilesMatch>
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME} \.(js|css)$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]

##
# Rewrite TYPOlight URLs
##
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*\.html)$ index.php/$1 [L]

Inhalt der vHost:

Code:

# 20_froxlor_normal_vhost_laurentiusweb.de.conf
# Created 31.03.2010 15:45
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 4 - CustomerID: 2 - CustomerLogin: cu0547
<VirtualHost 88.198.25.35:80>
  ServerName laurentiusweb.de
  ServerAlias www.laurentiusweb.de
  ServerAdmin gemeindediakon@gmail.com
  DocumentRoot "/var/syscp/webs/cu0547/"
  SuexecUserGroup "cu0547" "cu0547"
  <Directory "[..]/">
[..]
    Options +ExecCGI FollowSymLinks SymLinksIfOwnerMatch 
    AllowOverride All
    Order allow,deny
    allow from all
  </Directory>
  ErrorLog "-"
  CustomLog "/-" combined
</VirtualHost>

Ich habe apache schon lange nicht mehr angerührt oder liegt es irgendwie an TL?

Danke für eure Hilfe.

**arnoldB** · 03.04.2010, 22:01

kennt da jemand mögliche Fehlerquellen?

**Sebastian** · 04.04.2010, 09:05

HI

liegt TL vielleicht in einem Unterverzeichnis? Dann musst du die RewriteBase entsprechend anpassen.

Sebastian

**arnoldB** · 04.04.2010, 12:19

Hallo Sebastian,

nein, die Basisangabe ist korrekt. Liegt es vielleicht an falschen Dateirechten von eben irgendwelchen Dateien im CMS die ich noch berichtigen muss?

Frohe Ostern!

Gruß Arnold

**Andreas** · 04.04.2010, 13:32

Du hast oben den Code von der .htaccess gepostet. Ist der original? Wenn ja, wäre es einfacher ihn nicht zu posten, wenn nein, wäre es besser du würdest nur die Unterschiede zum Original zeigen, so müssten wir uns die mühsam erarbeiten.

Die original .htaccess funktioniert bislang problemlos. Lass mal die typolight-check.php drüber laufen.

**arnoldB** · 04.04.2010, 14:42

Zitat von Andreas

Du hast oben den Code von der .htaccess gepostet. Ist der original? Wenn ja, wäre es einfacher ihn nicht zu posten, wenn nein, wäre es besser du würdest nur die Unterschiede zum Original zeigen, so müssten wir uns die mühsam erarbeiten.

Die original .htaccess funktioniert bislang problemlos. Lass mal die typolight-check.php drüber laufen.

Hallo,

die htaccess habe ich 1:1 aus TL unverändert geposted.

Der TL-Check deutet: http://www.laurentiusweb.de/Xtypolight-check.php?hide=1

(die vielen 777 Fehler sind mir bekannt...)

**Sebastian** · 04.04.2010, 14:53

HI

Manche Provider (Kontent, beispielsweise) geben keine CHMOD-777-Dateien heraus. Normalisiere das doch mal, wie es der Check empfiehlt, dann sollte der Server die Dateien auch ausliefern.

Sebastian

**arnoldB** · 04.04.2010, 15:02

Zitat von Sebastian

HI

Manche Provider (Kontent, beispielsweise) geben keine CHMOD-777-Dateien heraus. Normalisiere das doch mal, wie es der Check empfiehlt, dann sollte der Server die Dateien auch ausliefern.

Sebastian

Die URL-Umschreibung ging auch davor nicht. Behebe gerade alle Rechteprobleme. Ich vermute das Problem an den vHost, den der Provider bin ich selbst.

**arnoldB** · 04.04.2010, 15:12

Stand: 16:11 Uhr => URL-Rewrite geht noch nicht, trotz korrektem TL-Satus (http://www.laurentiusweb.de/Xtypolight-check.php?hide=1)

**Sebastian** · 04.04.2010, 15:55

HI

Ah. Du hast den URL-Suffix ausgeschaltet. Dann musst du natürlich die letzte Zeile der .htaccess auch entsprechend anpassen (Foren-Suche hilft).

Und: Wenn du der Hoster bist, ändere doch mal das:
Upload maximum filesize • 2M Recommended setting is 8M or greater.

Sebastian

**arnoldB** · 04.04.2010, 16:03

Hallo Sebastian,

ich kann auf Anhieb keine bekannten Problemlösungen betreffen der RewriteRule und Suffixänderungen finden.

Das mit der filesize ist mir bekannt, da ich aber ein spezielles Management system kann ich die php.ini nicht so einfach ändern, daran sitze ich aber noch.

Gruß Arnold

***xchs*** · 04.04.2010, 16:05

Zitat von arnoldB

die htaccess habe ich 1:1 aus TL unverändert geposted.

Also, das kann mit Sicherheit nicht stimmen, da hier

Code:

##
# Rewrite TYPOlight URLs
##
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .*.html$ index.php [L]

in der RewriteRule ein Backslash fehlt!

**arnoldB** · 04.04.2010, 16:33

Hallo,

tatsächlich scheint die Datei nicht das Original zu sein.

Danke für die Meldung und Entschuldigung für die falsche Info von mir.

Die URL-Umschreibung funktioniert noch nicht.

***xchs*** · 04.04.2010, 16:40

Hallo arnoldB,

Du schreibst leider nicht, ob sich dadurch jetzt irgendwas geändert hat. Ich nehme daher mal an, es funktioniert immer noch nicht oder?

Je nach dem welche Apache-Version Du verwendest könntest Du auch mal probieren, die letzte Zeile Deiner ".htaccess" folgendermaßen abzuändern:

Code:

RewriteRule .*\.html$ index.php [L]

**Andreas** · 04.04.2010, 16:41

Und schon wieder. Du brauchst hier keine Core-Dateien zu posten, die haben wir alle selber.

**arnoldB** · 04.04.2010, 16:42

Hallo,

nein beim Aufruf von http://www.laurentiusweb.de/startseite wird mir immer noch 404 error ausgegeben.

Danke für deinen Vorschlag, hat leider nicht geklappt.

(Installiert ist apache2)

//Andreas: Ok werde ich in Zukunft beherzigen.

**arnoldB** · 04.04.2010, 16:46

Stand 17.45 Uhr: Funktioniert nun. Habe das Suffix .html wieder eingetragen. Ich probiere jetzt mal das ganze ohne html Suffix.

Danke euch allen für die einmal wieder extrem schnelle Unterstützung!

Sowas findet man nur hier..

***xchs*** · 04.04.2010, 16:47

Das hier hast Du Dir angesehen: https://community.contao.org/de/show...ll=1#post13749 ?

**arnoldB** · 04.04.2010, 16:50

Vielen Dank

**Sebastian** · 04.04.2010, 18:01

HI

siehst du, das habe ich über die Suche auch gefunden…

Sebastian

**chris** · 04.04.2010, 18:25

ich kann dir nur abraten TL ohne Suffix zu betreiben, denn das interne Errorhandling funktioniert dann nur sehr eingeschränkt... siehe Beitrag hier

Bisher hat dafür auch noch niemand eine Antwort oder gar eine Lösung geben können, von daher bin ich reumütig zum .html Suffix zurückgekehrt.

**Sebastian** · 04.04.2010, 18:42

HI

Ich verwende dieses Setup in etlichen Installationen und hatte nie ein Problem. Allerdings sind die Fehlerseiten auch keine Weiterleitung, sondern eine echte Fehlerseite.

Sebastian

**arnoldB** · 04.04.2010, 18:52

mich plagt schon wieder ein ganz anderes Problem

:

Wenn ich versuche die URL-Umschreibung (andere TL-Installation) zu aktivieren, bleibt die Einstellung nicht gespeichert.

Habe der .htaccess bereits 777 chmod gegeben aber geholfen das dennoch nichts. tl-check befand alle dateien für korrekt.

**MacKP** · 04.04.2010, 18:57

Zitat von arnoldB

mich plagt schon wieder ein ganz anderes Problem

:

Wenn ich versuche die URL-Umschreibung (andere TL-Installation) zu aktivieren, bleibt die Einstellung nicht gespeichert.

Habe der .htaccess bereits 777 chmod gegeben aber geholfen das dennoch nichts. tl-check befand alle dateien für korrekt.

Dann ist der SMH dort nicht eingerichtet obwohl du den brauchst oder er ist noch nicht richtig eingerichtet...
Bemühe dazu doch bitte mal die Suche.. das beantworten wir ca. 3 mal die Woche..

Viele Grüße

***xchs*** · 04.04.2010, 18:59

Naja, die Zugriffsrechte der ".htaccess" spielen in diesem Fall aber keine Rolle.

Dann wohl eher, ob Deine "localconfig.php" problemlos beschreibbar ist. Dort müsste nämlich ein Eintrag

PHP-Code:


$GLOBALS['TL_CONFIG']['rewriteURL'] = true;

vorhanden sein, wenn Deine Einstellung im Backend richtig übernommen wurde.

**arnoldB** · 04.04.2010, 19:04

Dir Voreinstellung in der localconfig war false => geändert in true

Die restlichen Parameter stimmen in der localconfig.

tl-check sagt: "You should be able to run TYPOlight without the Safe Mode Hack."

die einstellungen stimmen nun, doch das backend lügt mir den bereich smh und rewrite mit falschen einstellungen vor. (leere felder)

http://bofb-mov.com/Xtypolight-check.php?hide=1

Stand 20.05 Uhr: Rewrite Einstellungen werden im BE richtig angezeigt. FTP settings nicht.

***xchs*** · 04.04.2010, 19:08

Irgendwas wird dann aber doch noch nicht ganz funktionieren, denn _richtig_ wäre ja andersrum, also dass Deine Einstellungen im Backend in Deine "localconfig.php" gespeichert werden, ohne dass Du dort manuell etwas ändern bzw. eintragen müsstest...

**arnoldB** · 04.04.2010, 19:09

ja das ist mir bewusst aber erklären kann ich das natürlich nicht.

**Sebastian** · 04.04.2010, 19:27

HI

mach mal die Rechte wieder auf 644, ich denke, die Datei gehört einfach dem falschen Nutzer.

Sebastian

**chris** · 04.04.2010, 19:57

Nochmals zur falschen Fehlerbehandlung bei Nutzung von TL ohne URL-Suffix

Ich verwende dieses Setup in etlichen Installationen und hatte nie ein Problem. Allerdings sind die Fehlerseiten auch keine Weiterleitung, sondern eine echte Fehlerseite.

dann schau mal auf Sebastians Seite und gib mal zB: folgendes in die Adresszeile des Browsers ein:

http://www.laurentiusweb.de/jugendkreis-news/bla
Dann weißt du, was ich meine mit falschem Errorhandling.... da wird nämich ganz brav die Seite darunter angezeigt.
Die gesamte Problematik ist wie gesagt hier schon beschrieben.

Gruß Chris

**arnoldB** · 04.04.2010, 20:18

man nennt mich auch Arnold

Nachtrag: Geänderte Einstellungen (E-Mail) in den BE Einstellungen werden zwar umgesetzt aber nach dem Reload nicht im BE für geändert angezeigt.

Ähnlicher Fall bei den Stylesheets. habe der von tl erstellten css datei 777 gegeben, jetzt werden da änderungen richtig angenommen.