It can happen to everyone of us: just install the SlimStat plugin for WordPress and blam – blog gone. What stays is an blank blog. So I wrote this short step-by-step fix, how to install SlimStat correctly.

First, you should check if a table for SlimStat was created in the MySQL database (PREFIX_slimstat), if the PHP memory limit is big enough and – this was my failure – if the SlimStat cache is writeable. In case of the last point, make the folder writeable for all:

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

After the next call of SlimStat a folder cache/ with the rights of the Apache server will be created. Instead of using a permanent full write access we hand the folder over to the control of the Apache server.

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

Now, we can remove the access for non-owner (other) with chmod o-x.

The reason, why I chose the SlimStat plugin out of a plenty of statistical plugins, was a clear set of function instead of a lot less necessary functions about when, how long and whatever a browser touches your blog. And another argument: you are not dependent on notifiable services like Google Analytics, which – nevertheless it’s Google – can have also some pros. Btw. the first information of interest offered by the SlimStat plugin: it seems like this little GoogleBot fellow scans the whole Internet – everyday. Interesting…

Tagged with:
 

5 Responses to SlimStat für WordPress

  1. Olli says:

    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 says:

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

  3. Olli says:

    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 says:

    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 says:

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