Wer kennt das nicht: Man installiert das SlimStat-Plugin in WordPress und der Blog ist nicht mehr erreichbar – nur noch weiße Seite. Dafür hier eine kurze Lösung. Für alle, die vor dem gleichen Problem stehen, Stichwort blank blog.

Sofern die Tabellen in der WP-Datenbank erstellt wurden (PREFIX_slimstat) und das PHP Memory Limit groß genug ist, sollte überprüft werden, ob der Cache des Plugins Schreibrechte hat. Sollte das nicht der Fall sein, muss man den Ordner beschreibar machen.

root@host:~# chmod o+x /[...]/wordpress/wp-content/plugins/wp-slimstat/cache/

Beim nächsten Aufruf der Seite wird dann der File cache.php im Ordner cache/ mit den Rechten des Apache-Servers erstellt. Nun kann man die Schreibberechtung belassen oder den Ordner in Hand des Apache-Servers geben.

root@host:~# chown www-data:www-data /[...]/wordpress/wp-content/plugins/wp-slimstat/cache/

In dem Fall kann die Schreibberechtigung des Ordners für alle anderen (other)  wieder entfernt werden [chmod o-x].

Im Weiteren erscheint das SlimStat-Plugin aus einer großen Auswahl an Plugins für Statistiken als recht aktuell, brauchbar und nicht überladen. Viele andere bieten sehr viel unnötige Information oder basieren auf anmeldepflichtigen Diensten wie Google Analystics und kamen somit für mich nicht in Frage, wenn auch sie Vorteile haben.

Und der Einsatz des Plugins hat auch schon viele interessante Informationen ans Tageslicht gefördert. So z.B. wie oft doch der Google-Robot scheinbar das komplette Netz durchforstet. Aber auch woher eine Weiterleitung auf den Blog erfolgte und bietet somit Möglichkeiten sich eventuell besser zu plazieren.

Getagged mit
 

5 Responses to SlimStat für WordPress

  1. Olli sagt:

    Sowas passiert nur, wenn der Indianer alle Skripts unter einer Benutzerkennung (der eigenen) ausführt, glücklicherweise gibts ja FCGI und Co (sprich PHP nicht als mod_php sondern via CGI (FCGI bzw. FastCGI))… Hat auch den Vorteil das Skripts nicht auf Dateien von anderen VHosts zugreifen können (falls open_basedir und co nicht aktiv sind/oder sonst was falsch eingestellt ist)

    Schicke Stats bekommste auch mit Piwik oder OWA 😉

  2. Kex sagt:

    Ähh ok. Seh ich das dann richtig, dass FCGI innerhalb des Apache aktiviert wird? Und mit welchen Rechten laufen dann die Skripts?

  3. Olli sagt:

    Japps, mod_fcgi (oder mod_fastcgi, falls ersteres nicht verfügbar ist) + suexec (was dann schlussendlich für den Benutzerwechsel zuständig ist).

    Mit den Rechten des Benutzers den du bei dem entsprechenden VHost konfiguriert hast. Damit reicht dann halt auch n 0700 etc., nichtmal Gruppenrechte sind notwendig, kann man mehrere VHosts einfach besser gegeneinander abschotten. Kostet n bischen Leistung, falls es der Server nicht mitmacht gäbe es noch suphp (wird aber glaube ich nicht mehr aktiv gepflegt?).

  4. Kex sagt:

    Habe mal nach dem Paket gesucht und gefunden, dass es schon irgendwie im Plesk mit drin sein müsste (libapache2-mod-fcgid-psa). Darauf hin habe ich unter den Hosting Settings für die rootdomain mal tiefer rein geschaut und die Option „PHP support (run as [] , PHP ’safe_mode‘ on )“ gefunden. Da dann FastCGI, statt Apache2 eingestellt. Jetzt wird die Datei mit den Rechten der Domain erstellt (rootdomain:psacln), wie auch schon der Rest des vhosts. Und in Sachen Geschwindigkeit oder RAM, seh ich keinen Unterschied, genau genommen sogar weniger RAM-Nutzung.

    Dann nur noch die Frage: Subdomains werden und können nicht als eigene vhosts geführt oder? Zumindest sieht es so aus, als wäre es nicht vom Plesk-Panel aus möglich.

    PS: Plesk ist zwar praktisch, weil es die Einstellungen zentralisiert, aber uuuuuuunglaublich unübersichtlich! :-!

  5. Olli sagt:

    Du kannst Subdomains als „reguläre“ Domains eintragen, dann hast du alle Vorteile einer „regulären“ Domain…