Archive for the 'Programmierung' Category

MySQL-Dump lokal einspielen

Warum bietet der phpMyAdmin eigentlich keine Lösung dafür, Daten die auf dem Server liegen direkt einzuspielen? Auch in der letzten 3er Version gibt es nur den grausamen HTTP-Upload. Macht nicht wirklich Spaß größere Dumps zu übertragen, auch wenn es lokal stattfindet.

Naja, zum Glück gibt es SSH für Webserver und lokal unter Windows können wir das ganze noch einfacher erledigen.

Zuerst muss eine neue Datenbank erstellt werden. Dies kann man entweder per phpMyAdmin oder per Kommandozeile erledigen:
C:\xampp\mysql\bin>mysqladmin –user=root create datenbankname
Danach kann der Dump (in meinem Fall 390MB groß) eingespielt werdem:
C:\xampp\mysql\bin>mysql –user=root datenbankname < C:\backup2010_02_12__23_00.sql
(evtl. muss noch ein Passwort mit –pass=xxx angegeben werden)

Wenn nach einer kurzen Wartezeit keine Fehlermeldung auftaucht, hat alles geklappt.

Vermutlich wird es aber (bei größeren Dumps) zu einer Fehlermeldung ähnlich dieser kommen:
ERROR 2006 (HY000) at line 51206: MySQL server has gone away
(Die Zeilennummer wird natürlich nicht die selbe sein)

Die Meldung ist ziemlich sinnlos, die Lösung relativ einfach.
In der my.ini muss der Wert für die maximale Packetgröße einer SQL-Query erhöht werden:
max_allowed_packet = 16M
Der Standard-Wert ist 1M.

PHP, cURL und die SESSION

Mir hat ein kleines Problem beinahe das Genick gebrochen … mehrstündige Recherchen im Netz brachten mich keinen Meter weiter, ich hoffe der Artikel hilft dem ein oder anderen bei der “Fehlersuche” – aber fangen wir von vorne an.

Sessions sind eine prima Sache, wer Daten über mehrere Scripte hinaus austauschen will, der greift darauf zurück.
Leider passiert es nun manchmal, dass man ein eigenes Script als fertiges HTML benötigt – ein include() per HTTP fällt aber auf vielen Servern dank der allow_url_include Konfigurationseinstellung flach, also muss cURL her.
Mit cURL können wir ein beliebiges Script per HTTP aufrufen und den Inhalt in der aktuellen Seite einbinden, ohne dass ein User etwas davon merkt.

Wer nun aber denkt, er könne die Session-Daten auch in dem Script abgreifen, das per cURL geladen wird, der wird sein blaues Wunder erleben. cURL generiert jedesmal eine neue Session-ID, anstatt die vorhandene fortzusetzen – ist ja auch klar, das ist, als ob man einen zweiten Browser startet, also übergibt man die Session-ID. Entweder kann man diese einfach als GET-Parameter anhängen, oder man setzt eine cURL-Option für ein Cookie.

Das sieht dann so aus:

Wer jetzt das Script aufruft, wird mit einer Sanduhr belohnt. Das Script läd und läd und hört nicht auf. Ein neuer Seitenaufruf schlägt ebenfalls fehlt und wird wieder mit einer Sanduhr belohnt. Der User denkt dann sein Browser wäre abgestürzt, weil nichts mehr funktioniert.

Warum?

Wenn man es weiß, ich die Lösung (wie immer) ganz einfach.
PHP schreibt die Session-Daten erst bei der Beendigung eines Scripts in die Datei auf dem Server. Während das Script läuft, ist die Datei gesperrt, so dass nicht mehrere Scripte gleichzeitig die Daten ändern. Wir müssen also dafür sorgen, dass die Session-Daten gespeichert werden, bevor wir das nächste Script aufrufen. Das erledigt session_write_close(); für uns.

Die Daten in der Superglobalen $_SESSION stehen nach dem Schließen selbstverständlich noch (read-only) zur Verfügung.
Lese- und Schreibrechte hat jetzt aber das per cURL aufgerufene Script.

MySQL: Zufallsdaten, die sich nur einmal am Tag ändern

Wer kennt das nicht, man will einen zufälligen Datensatz (Rezept/Zitat/Bild) aus einer Tabelle holen und anzeigen lassen.
Soweit kein Problem, doch was ist, wenn ein Besucher etwas gesehen hat und nach dem Besuch der zweiten oder dritten Seite nochmal das zufällig angezeigte Rezept/Zitat/Bild sehen will? Wir brauchen also einen Zufallswert, der sich nur einmal täglich ändert.

Die Lösung ist: Wir geben dem rand() einfach einen Wert zur Initialisierung mit.

select *
  from tabelle
 order by rand(date_format(now(), '%d%m%Y'));

Dazu nutzt man einen Integer, den bilden wir einfach aus dem aktuellen Tag, Monat und Jahr – und da sich dieses Datum nur einmal am Tag ändert, bekommen wir Zufallsdaten zurückgeliefert, die sich nur einmal am Tag ändern. :)

WordPress Bilder-Upload bei domainFACTORY

Nach der erfolgreichen Installation habe ich natürlich versucht ein Bild in einem Artikel einzubinden. Eigentlich nichts weltbewegendes, “Hochladen/Einfügen” ausgewählt, das Bild gewählt und übertragen.
Nanu, da kommt gar keine Vorschau?!
Egal, wir veröffentlichen den Artikel erstmal – und siehe da, wir sehen … nichts!

Gut, dann rufen wir den Pfad zum Bild direkt auf – “Forbidden”, aha, also sind die Rechte irgendwo falsch gesetzt.
Schnell geprüft: WordPress hat den Pfad korrekt angelegt und auch das Bild gespeichert: “/uploads/2009/10/bild.jpeg”. Allerdings sind die Rechte falsch gesetzt. Die Pfade sind auf 710, das Bild auf 600 – bei domainFACTORY muss es aber 750 und 640 sein.

Schnell geguckt ob sich das Verhalten irgendwo in WordPress anpassen lässt – nichts gefunden.

Das ist aber auch gar nicht nötig, es reicht, wenn man den Pfad für die uploads mit den Rechten 750 versieht. Danach werden die Bilder o.ä. automatisch mit den korrekten Rechten von 640 versehen.