Zur Navigation

Nach Bearbeiten der htaccess kommt "Scriptfehler 500"

1 Martin

Hallo,
nachdem eine Test-Installation (neue Wordpress-Website) auf einer Subdomain fertig war und nun die alte statische Website ersetzen sollte, habe ich in Wordpress unter "General Settings" die "neue" URL eingetragen und die Domaineinstellung in meinem Kundenmenü geändert.

Bin nach der URL-Änderung in WP zwar erst mal rausgeflogen, konnte mich dann aber später doch wieder einloggen. Ist das normal? Na ja, ging dann jedenfalls.

Dann änderte ich die htaccess, weil gegenüber der Test-Site ein paar Sicherheitsdinge und insbesondere auch ein Redirect für die Unterseiten-URLs erfolgen soll, d.h., das ".html" soll nun wegfallen.

Nach dem Ändern der htaccess bin ich dann aber aus Wordpress rausgeflogen und konnte mich auch nicht mehr einloggen: "500 Scriptfehler Unbekannte URL, haben Sie sich vertippt...blabla.."

Gleich nach dem Ändern habe ich Filezilla geschlossen und bin nochmal neu rein, habe mir die Änderungen in der htaccess angesehen. War alles wie gewünscht. In Filezilla ist eine Einstellung vorhanden, dass "dotfiles" wie .htaccess als ASCII-Dateien behandelt werden. Als Übertragungstyp ist "Automodus gewählt. Am Übertragungstyp kann es also wohl nicht liegen. Rechte wie vorher "740".

Warum macht das Ändern der htaccess Probleme?
Der Redirect funktionierte übrigens auch nicht, habe einen Link im Web (mit .html) auf eine der Unterseiten geklickt und es wurde nicht auf "ohne .html" umgeleitet.

Die htaccess sieht so aus:

# xmlrpc.php deaktivieren zwecks sicherheit
<Files "xmlrpc.php">
Order allow,deny
Deny from all
</Files>
   
  # Kein Zugriff auf Dateien mit WP-Version
<FilesMatch "(liesmich.html|readme.html|liesmich.txt|readme.txt|licence.txt)">
Order deny,allow
Deny from all
</FilesMatch>
   
  # Keine php-Fehlermeldungen mit Serverpfad
php_flag display_errors off
     
  #301-redirect: page.html zu page
RewriteRule ^([\w-]+)\.html$ http://www.hauptdomain.de/$1 [R=301,L]

  # BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
  # END WordPress


Martin

25.05.2015 21:05

2 Jörg

"500 Scriptfehler Unbekannte URL, haben Sie sich vertippt...blabla.."

Wie war denn der genaue Wortlaut?

"haben Sie sich vertippt" passt eher zu einem Server-Fehler 404

25.05.2015 21:36

3 Martin

Hallo Jörg,
Ja, inhaltlich klang das tatsächlich so ähnlich wie bei einer 404. Dachte ich mir auch schon. Es war aber definitiv "500 Scriptfehler".

Bin mir nicht mehr zu 100% sicher, aber es lautete wohl so:

"500 - Scriptfehler

leider ist ein Problem aufgetreten. Die angeforderte Seite hat einen Script-Fehler verursacht.

Haben Sie sich vielleicht vertippt oder eine alte URL aufgerufen? Wenn nicht, informieren Sie bitte den Webmaster dieser Homepage per Email. Um zu der vorherigen Seite zurück zu kehren, verwenden Sie bitte einfach die "Zurück" - Taste Ihres Browsers. "

Die Zurück-Taste des Browsers klappte aber nicht.

Kann man wenigstens etwas sicher ausschließen? Code der htaccess? Übertragungstyp-Fehler?

Per FTP mit Rechtsklick auf die bestehende htaccess klicken und dann auf "Bearbeiten/Ansehen" öffnet automatisch das Windows-eigene Notepad. Also nicht Notepad++, sondern das ziemlich einfache "Notepad" von Windows. Googeln hat aber ergeben, dass das ein "ASCII-Editor" ist, der für htaccess-Erstellung oder -Änderung offenbar durchaus geeignet ist - im Gegensatz zu "Word", das irgendwelche tags hinzufügt.

Notepad von Windows kann es also auch nicht sein, oder?





Martin

25.05.2015 22:03 | geändert: 25.05.2015 22:11

4 Jörg

Einen Syntax-Fehler enthält die .htaccess Datei wohl nicht, zumindest lässt sie sich auf meinem Test-System normal ausführen, inklusive Weiterleitung.

Möglicherweise ist aufgrund der Server-Konfiguration die ein oder andere Direktive nicht erlaubt. Der Grund eines 500er Fehlers steht in der Error-Logdatei des Webservers, auf welche man bei einem normalen Webspace allerdings keinen Zugriff hat

Du kannst ja mal testweise jeweils einen Anweisungsblock (mit # am Zeilenanfang) auskommentieren, ob dann der Fehler verschwindet

Notepad von Windows kann es also auch nicht sein, oder?

Notepad fügt Windows-Umbrüche hinzu, diese sollten allerdings bei einer Übertragung im ASCII-Modus konvertiert werden.

Wenn Umlaute enthalten sind, fügt Notepad gerne mal einen BOM hinzu. Du solltest dann sicherstellen, dass die Datei nicht in UTF8 gespeichert ist.

Ansonsten lässt sich in Filezilla auch ein anderer Standard-Editor einstellen:

http://www.tipps-archiv.de/filezilla-dateien-bearbeiten.html

26.05.2015 09:23 | geändert: 26.05.2015 09:23

5 Martin

Umlaute sind nirgends zu sehen, aber wenn ich sicher gehen will, dann wäre Notepad++ als Standard-Editor die sicherste Wahl?

Wordpress beschreibt Umzüge in deren Codex recht ausführlich. Es trifft zwar nicht exakt meinen Fall, weil ich die Domaineinstellung ändere anstatt WP in ein anderen Verzeichnis zu verschieben, aber hier steht ein interessanter Punkt 10:
http://codex.wordpress.org/Moving_WordPress#Moving_Directories_On_Your_Existing_Server

If you are using Permalinks, go to the Administration > Settings > Permalinks panel and update your Permalink structure to your .htaccess file, which should be in the same directory as the main index.php file.

Müsste ich vielleicht gleich nach Domaineinstellung und URL-Änderung in WP, also noch vor der htaccess-Änderung, ein solches "Resave" der Permalink-Einstellung machen?



Martin

26.05.2015 10:30

6 Jörg

dann wäre Notepad++ als Standard-Editor die sicherste Wahl?

Du kannst mit Notepad++ auch UTF8 ohne BOM schreiben, sowie Unix-Umbrüche verwenden (wobei letzteres nicht unbedingt nötig ist, wenn der FTP-Client im ASCII-Modus hochlädt)

If you are using Permalinks, go to the Administration > Settings > Permalinks panel and update your Permalink structure to your .htaccess file, which should be in the same directory as the main index.php file.

In der .htaccess Datei rewritet Wordpress alle nicht vorhandenen Verzeichnisse und Dateien ganz banal auf die index.php. Daran sollte sich eigentlich nichts ändern, wenn sich die Perma-Link-Struktur ändert. Aber du kannst es ja ausprobieren

Wenn die Weiterleitung nicht funktioniert, hat das allerdings nichts mit WordPress zu tun.

Zum Debuggen würde ich wie gesagt mal folgendes machen:

Zitat von Jörg
Du kannst ja mal testweise jeweils einen Anweisungsblock (mit # am Zeilenanfang) auskommentieren, ob dann der Fehler verschwindet

Also z.B.:

# xmlrpc.php deaktivieren zwecks sicherheit
#<Files "xmlrpc.php">
#Order allow,deny
#Deny from all
#</Files>

... und auf diese Weise einen Block nach dem anderen durchgehen.

26.05.2015 15:59

7 Martin

In der .htaccess Datei rewritet Wordpress alle nicht vorhandenen Verzeichnisse und Dateien ganz banal auf die index.php. Daran sollte sich eigentlich nichts ändern, wenn sich die Perma-Link-Struktur ändert.


Sie ändert sich gar nicht mal. Es bleibt bei "Custom Structure: ...../%postname%
Ich hatte Punkt 10 im codex so verstanden, dass man das immer machen sollte, wenn sich die URL ändert. Bei manchen Tutorials über WP-Umzüge wird das als "Resave" bezeichnet.

Vielleicht sollte ich die alte htaccess komplett löschen (oder umbenennen?) und WP eine neue anlegen lassen. Und erst dann meine Änderungen ergänzen.


Du kannst ja mal testweise jeweils einen Anweisungsblock (mit # am Zeilenanfang) auskommentieren, ob dann der Fehler verschwindet

Wie wäre es, wenn ich schon vor der Umstellung, also die "alte" htaccess, mit den auskommentierten Ergänzungen versehe und dann später blockweise die Rauten rausnehme? Kommt wahrscheinlich aufs Gleiche raus, aber ginge schneller. Solange die 500 für Besucher kommt, ist die Site nicht zugänglich...

Du vermutest also, dass der Code zwar richtig ist, aber der Server trotzdem mit irgendetwas davon ein Problem hat?

Martin

26.05.2015 16:58 | geändert: 26.05.2015 16:59

8 Jörg

Wie wäre es, wenn ich schon vor der Umstellung, also die "alte" htaccess, mit den auskommentierten Ergänzungen versehe und dann später blockweise die Rauten rausnehme?

Ja, so kannst du das natürlich auch machen

Du vermutest also, dass der Code zwar richtig ist, aber der Server trotzdem mit irgendetwas davon ein Problem hat?

Ich vermute nicht nur: auf meinem Test-System hat der von dir gepostete .htaccess Code keinen Server-Fehler verursacht. Entweder deine .htaccess Datei ist durch irgendwelche Steuerzeichen korrumpiert oder die spezielle Server-Konfiguration macht Probleme. Mehr Möglichkeiten sehe ich nicht.

26.05.2015 18:41 | geändert: 26.05.2015 18:42

9 Martin

Bin wie vorgeschlagen schrittweise vorgegangen und merkte zu meiner Überraschung, dass es daran lag:

php_flag display_errors off

Domainfactory bietet das nicht an in dieser Form. Man kann es aber im Kundenmenü über eine php.ini-Einstellung machen.

Der Support-Mitarbeiter, den ich jetzt gerade dran hatte, hat es sofort von sich aus erwähnt, als er die htaccess sah. Die beiden anderen, die ich gestern und heute nachmittag dran hatte, waren offenbar... "weniger kompetent".

Danke!



Martin

26.05.2015 21:27

10 Jörg

Wenn PHP nicht als Apache-Modul läuft, sondern beispielsweise über FastCGI, dann steht die Direktive php_flag nicht zur Verfügung. Das ist dann wohl bei Domainfactory der Fall.

27.05.2015 09:37 | geändert: 27.05.2015 09:37