Tobis Bilderbox …für die meisten nichts, aber für wenige viel

Sorry, aber davon gibt es derzeit (noch!) keine deutsche Version…

Recently I tried to run a portable version of XAMPP for a local testing environment in combination with Adobe Dreamweaver and wordpress. Unfortunately I could not start the Apache server from the XAMPP control panel. The little green “running” sign appeared for about two seconds and then disappeared again. Also the XAMPP start page did not work. When I tried to use the start script, the prompt told me:

make_sock: could not bind to address 0.0.0.0:443 no listening sockets available, shutting down

meaning, that the TCP port 443 was allready in use by another aplication. But since I did not install any other server software, I was confused which program would dare to occupy the standard https port… A quick google search helped me to figure out some “command prompt magic” to find the delinquent. The command

netstat -ano | findstr :443

returned

TCP 0.0.0.0:443 0.0.0.0:0 LISTEN 5104

which helped me to find the process ID of the program using port 443, in this case 5104. But since this PID number did not show up in the windows task manager (which scared me a little bit), I again did some googling and found the tasklist command:

tasklist | findstr 5104

revealed that Skype.exe was responsible for the “port occupation”. So I opened up Skype and started looking for reasons. Under “Tools > Options > Advanced > Connection” I found a checkbox labled “Use port 80 and 443 as alternatives for incoming connections”… I unchecked it, restarted skype, et voilà: XAMPP worked like a charm!

Skype setting to use TCP ports 80 and 443

Hope this helps you (and me again) sometimes… Cheers, Tobi

In diesem Beitrag gibt es leider keine schönen Fotos und ich gebe zu er ist ein wenig geeky, aber ich habe mir gedacht, dass er vielleicht jemandem helfen kann, der vor dem gleichen Problem steht.

Nachdem ich WordPress aktualisiert hatte (in meinem Fall auf Version 3.0.1), hat meine Webseite plötzlich aufgehört zu funktionieren. Sie hat einfach gar nichts mehr angezeigt, nur noch eine weiße Seite ohne jeglichen Quellcode. Ich kam nicht einmal mehr in das Admin-Backend.

Nech langer Rumtüftelei mit Konfigurationsdateien und WP-Sourcen und nach gefühlten 100 Restores der Datenbank, fand ich heraus, dass es irgendwas mit dem WP Super Cache plugin zu tun hatte. Nachdem ich in der wp-config.php die Zeile “define(‘WP_CACHE’, true); //Added by WP-Cache Manager” gelöscht hatte konnte ich mich wieder in den Admin-Bereich einloggen.

Leider fügt das Plugin beim öffnen der Konfigurationsseite diese Zeile immer wieder automatisch in die wp-config.php ein, was jedes mal wieder zu einer überhaupt nicht funktionierenden Seite führte.

Aber jetzt war der Fehler wenigstens greifbar. Ein wenig stöbern in der offiziellen Installationsanleitung führte mich dann auf die richtige Spur. In meinem Setup fehlten zwei Dateien:

Erstens eine .htaccess-Datei im Verzeichnis “/wp-content/cache/” mit folgendem Inhalt:


# BEGIN supercache
<IfModule mod_mime.c>
<FilesMatch "\.html\.gz$">
ForceType text/html
FileETag None
</FilesMatch>
AddEncoding gzip .gz
AddType text/html .gz
</IfModule>
<IfModule mod_deflate.c>
SetEnvIfNoCase Request_URI \.gz$ no-gzip
</IfModule>
<IfModule mod_headers.c>
Header set Cache-Control 'max-age=300, must-revalidate'
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html A300
</IfModule>
# END supercache

Und zweitens eine “wp-cache-config.php” im root-verzeichnis des Blogs. Eine Beispieldatei dieser kann man aus dem Pluginverzeichnins kopieren (wp-content/plugins/wp-super-cache/wp-cache-config-example.php) und in “wp-cache-config.php” umbenennen. Danach hat mein Blog (inklusive dem Suoer Cache Plugin) endlich wieder funktioniert. Yipee!

Wie bereits oben erwähnt hat mir die offizielle Installationsanleitung sehr weitergeholfen die man hier findet: http://wordpress.org/extend/plugins/wp-super-cache/installation/

Hoffe das hilft! Viel Erfolg!