Piwik

So, heute mal eine Testinstallation von Piwik erstellt (Version 2.0.2) und das WordPress-Plugin „WP-Piwik“ (Version 0.9.9.6) integriert, bisher erst mal als Site-Specific-Plugin.

Ich schaue mir das jetzt erstmal an, bevor ich das Plugin als Network-Plugin einstelle.

Edit 28.12.2013
Es gibt ja mehrere Archivierungs-Cronjob-Scripte, ein sh-Script und php-Script. Und beide laufen erst mal nicht. Im archive.sh Script muss in die Zeile 44 ein ‚php5-54LATEST-CLI‘ eingefügt werden

Laut Doku sollte die archive.php verwendet werden. Diese wird am besten ebenfalls mit der PHP-CLI aufgerufen werden. Da man bei DomainFactory keine Parameter bei den Cronjobs angeben kann kurz ein Script gebaut:

Update 3.7

WP-Update auf 3.7 bringt eine Autoupdatefunktion mit.

Klar, kann man das Abschalten, info’s gibt es hier: http://make.wordpress.org/core/2013/09/24/automatic-core-updates/.

Im Klartext: folgende Zeile in die wp-config.php eintragen unterbindet das automatische Update.

Will man nicht nur die Sicherheitsupdates (z.B. von 3.7.0 auf 3.7.1) mitnehmen, sonder auch größere Updates, folgendes in die wp-config.php einfügen:

Update 28.10.2013 :Die Einstellung von WP_AUTO_UPDATE_CORE kann folgende Werte enthalten:

Im Orginal ist zu lesen:

In order for Automatic Updates to be enabled, there are a few simple requirements:

  1. If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled
  2. If the install is running as a SVN or GIT checkout, automatic updates are disabled
  3. If the constants DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined, automatic updates are disabled
  4. If the constant WP_AUTO_UPDATE_CORE is defined as false, automatic updates are disabled
  5. Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
  6. Wp-Cron needs to be operational, if for some reason cron fails to work for your install, Automatic Updates will also be unavailable

Seitenoptimierung

page_speed_001

Zur Optimierung wird die Seite immer mal wieder getestet:

  • http://gtmetrix.com/reports/notiz.rj-server.de/rcaPxXwo
  • http://gtmetrix.com/reports/notiz.rj-server.de/zcQIgirz

In einem ersten Schritt geht es darum, dem Browser zu sagen, er solle gewisse Dateien für eine bestimmte Zeit cachen.
Google PageSpeed schlägt eine minimale Zeit von einem Monat vor.
Um dies zu erreichen, tragen wir nachfolgendes in die .htaccess-Datei ein.
Die Zeitangaben werden hierbei in Sekunden gemacht:
29030400 = 1Jahr
2592000 = 1Monat
604800 = 1Woche

Für die statischen Inhalte ist 1Monat eine gute Zeit:

page_speed_002

Dieser kleine Eintrag führt sofort zum Ergebniss, dass der Page Speed Grade von E (50%) auf D (61%) und der YSlow Grade von C (74%) auf B (82%) verbessert wird.

Versionierung bei WP

http://wpgrafie.de/schnipsel/wordpress-cache-busting-versionierung-dateinamen/

Das Script:

mehr Konstanten

Noch ein paar mehr Konstanten zur Konfiguration gefunden…

Diese Einstellungen sollten glaube ich bei einer MULTISITE Installation nicht verwendet werden..

Update: Bei wpGrafie.de gibt es noch ein paar mehr ….

WP-Konstanten

Diese Konstante nimmt die Editoren aus dem Backend und verbietet den Zugang dahin. Damit ist das Editieren von Theme und Plugin-Dateien aus dem Backend mit Standard-Lösungen nicht möglich.

Diese Konstante verbietet das Editieren, Modifizieren bzw. Ändern von Dateien aus dem Core, Plugins oder Themes. Die Menueinträge im Backend sind dann auch nicht sichtbar bzw. nutzbar.