Tipps, Tricks und Code-Snippets für Programmierer vom Programmierer

Heute habe ich auf meinen Statistik-Servern die neue Version 0.6 von Piwik installiert. Die Installation ging auf den ersten Blick reibungslos über die Bühne, nur bei genauerem hinsehen habe ich gemerkt das alle Daten die vor dem Update gesammelt wurden komplett verschwunden waren. Da auf den Servern auch jede Menge Domains von meinen Kunden getrackt werden kann schon ein wenig Panik auftreten.

Ein Blick in die Datenbank hat mir gezeigt das die Archiv-Tabellen alle noch vorhanden sind, nur verdammt wieso Zeigt Piwik diese Daten nicht mehr an?

Das Problem scheint daran zu liegen das Piwik nach dem Datenbank-Update für die Version 0.6 die Spalte “ts_created” in der MYSQL-Table “piwik_site” mit dem aktuellen Datum versieht und das ist auch schon das Problem wieso alle älteren Einträge nicht mehr Angezeigt werden.

Keine Panik hier kommt die Lösung:

Einfach den MYSQL-Befehl:

UPDATE piwik_site SET ts_created = '2010-01-01 00:00:00';

im phpMyAdmin ausführen und alle Daten die ab dem 01.01.2010 um 0.00 Uhr gesammelt wurden werden wieder angezeigt. Ihr könnt natürlich in dem MYSQL-Befehl das Datum auf den Zeitpunkt einstellen wann ihr Piwik das erste mal installiert habt.

Wenn euch diese Lösung auch geholfen hat würde ich mich über ein Feedback von euch freuen.

 [Sonstige Software]

Magento benötigt laut Systemvoraussetzungen eigentlich die “InnoDB storage engine”, da einige Webhoster dieses Feature erst in den Leistungsstarken Webhosting-Paketen anbieten gibt es hier eine Lösung für eure Testumgebung (Im Produktivbetrieb nicht zu empfehlen!). Dieser kleine Trick funktioniert aber nur wenn ihr vorher die “Sample Data” in eure MySQL-Datenbank eingespielt habt.

In der Datei “/magento/app/code/core/mage/install/mode/installer/Db.php” findet ihr ab Zeile 73 folgenden Code:

// check InnoDB support
if (!isset($variables['have_innodb']) || $variables['have_innodb'] != 'YES') {
Mage::throwException(Mage::helper('install')->__('Database server does not support InnoDB storage engine'));
}

dieses einfach so auskommentieren:

// check InnoDB support
// if (!isset($variables['have_innodb']) || $variables['have_innodb'] != 'YES') {
// Mage::throwException(Mage::helper('install')->__('Database server does not support InnoDB storage engine'));
// }

 [Magento]

Heute haben einige Host Europe Kunden mit folgender Fehlermeldung in Ihrem XT-Commerce – Online Shop zu kämpfen gehabt bzw. kämpfen immer noch:

Warning: session_start() [function.session-start]: open(/tmp/sess_xxxxxxxxx, O_RDWR) failed: Permission denied (13) in /is/htdocs/xxxxxxxxx/www/xxxxxxxxx/includes/application_top.php on line 298

Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at /is/htdocs/xxxxxxxxx/www/xxxxxxxxx/includes/application_top.php:298) in /is/htdocs/xxxxxxxxx/www/xxxxxxxxx/includes/application_top.php on line 298

Warnung
Warnung: XT-Commerce kann nicht in das Sessions Verzeichnis schreiben: /tmp. Die Sessions werden nicht funktionieren bis die richtigen Benutzerberechtigungen gesetzt wurden!

Kein Grund zur Panik dieser Fehler ist in 2 min gelöst einfach in folgenden Dateien die jeweilige Zeile abändern:

Dateien:
/includes/configure.org.php
/includes/configure.php
/admin/includes/configure.org.php
/admin/includes/configure.php

Zeile:
define(‘STORE_SESSIONS’, ”); // leave empty ” for default handler or set to ‘mysql’

ändern in:

define(‘STORE_SESSIONS’, ‘mysql’); // leave empty ” for default handler or set to ‘mysql’

Und nicht vergessen die Dateirechte der Config-Dateien nach dem bearbeiten wieder auf 444 zu setzen.

Ich hoffe wieder einigen mit diesem Tipp geholfen zu haben und das Host Europe das nächste mal jedem mit einem Newsletter versorgen kann.

 [XT-Commerce]

Da Detlef Holke vom CMB-Systeme Blog in die Blogosphäre getrommelt hat, werde ich ihm hiermit einmal unter die Arme greifen.

Seit einigen Tagen spielen einige ältere WordPress Blogs (Version 2.0.x) von 1&1 und Strato Kunden verrückt, sämtliche Blog Beiträge werden in der falschen Reihenfolge ausgegeben. Meine Vermutung dazu ist das 1&1 und Strato einige ihrer MySQL-Datenbanken (Version < MySQL 5.0.1) aktualisiert haben.

Hier folgt die Lösung:

In der Datei: /wp-includes/classes.php die Zeile:

$groupby = ” $wpdb->posts.ID “;

Ändern in:

$groupby = ” $wpdb->posts.post_date “;

Und in der Datei: /wp-includes/functions.php die Zeile:

” GROUP BY $wpdb->posts.id ORDER BY ” . $r['orderby'] . ” ” . $r['order'] . ” LIMIT ” . $r['offset'] . ‘,’ . $r['numberposts'] );

Ändern in:

” GROUP BY $wpdb->posts.post_date ORDER BY ” . $r['orderby'] . ” ” . $r['order'] . ” LIMIT ” . $r['offset'] . ‘,’ . $r['numberposts'] );

Auch wenn diese kleine Lösung einwandfrei funktioniert, empfehle ich jedem der noch so eine alte WordPress Version auf seinem Blog benutzt, diesen zu aktualisieren (Sicher ist Sicher).

 [WordPress]

Mit folgendem SQL-Befehl kann man den Wert vom Autoindex einer SQL-Tabelle auf den höchsten Wert von ID plus 1 setzen. Ohne die Tabelle leeren zu müssen.

ALTER TABLE tabellenname AUTO_INCREMENT=0;

 [MYSQL]