Archiv für den Monat: September 2009

Mehrfachdurchlauf von Variablen mit Smarty

Mein Problem war vor kurzem, dass ich an Smarty (die Template Engine) per PHP ein Array übergebe, welches dargestellt werden sollte.
So weit, so einfach, allerdings sollten die Daten sowohl Neben- wie auch untereinander dargestellt werden. Ich erklärs mal grafisch; die Ausgabe sollte in etwa so aussehen:

Wert1 Wert2 Wert3 Wert4
Wert5 Wert6 Wert7 Wert8

usw.

Ich hoffe, es ist klar, was ich machen will. So, es ist ebenfalls anzumerken, dass ich die Werte nur einmal an Smarty als Array übergebe, die ganze „Arbeit“ also in Smarty erledigt werden sollte – was ja auch so sein sollte, da es sich um eine reine Darstellungsproblematik handelte.

Wie das ganze in PHP zu lösen wäre ist mir klar, ich möchte allerdings wirklich streng den Code von der Darstellung trennen.

Hier mal die Lösung zum Problem:
Zunächste definiert man eine section, die das übergebene Array durchläuft, allerdings mit Schrittweite 4. Dannach übergibt man die gleiche Array-Variable an cycle und weist dem Ergebnis eine andere Variable zu, auf die man dann zugreift.

{section name=number loop=$myVariable step=4}
    {cycle values=$myVariable print=false
           assign=myData}
    {$myData.arrayElement|upper}
{/section}

Das ganze nun geschickt in eine Table oder div Struktur eingebaut bringt dann das gewünschte Ergebnis, vier Werte nebeneinander und dann beliebig viele untereinandern.

Ich hoffe, ich konnte nun dem ein oder anderen helfen…

Umlaute in webEdition – ein Problem

Unser neues Kundenprojekt soll mit webEdition umgesetzt werden. Dabei setzen wir die Version 6.0.0.6 ein, die aktuellste und installieren das ganze mit Hilfe des Online Installers. So weit, so gut. (Anmerkung: Alle Einstellungen stehen, soweit möglich, auf UTF-8).

WebEdition ist installiert, eine Vorlage ist erstellt und ein paar -Tags sind auch gesetzt. Nun heißt es “nur noch den Inhalt einfügen”.

Im Inhalt aber befinden sich Umlaute, solch bösen ä´s und ü´s und ö´s und so weiter. Beim ersten Speichern sieht alles noch gut aus. Also veröffentlichen und ansehen.

*bumm* Alle Umlaute sind maskiert, sowohl in Firefox und IE, als auch in Chrome, Opera, Safari und Iron. Komisch, komisch. Also in webEdition die Seite wieder öffnen.

*argl* Die Seite ist völlig verwurschtelt (sagt man so am Niederrhein), also total unbrauchbar.

Stunden später finden wir im Team folgendes raus: Befinden sich Umlaute im Text, so schneidet der WYSIWYG-Editor von webEdition 6.0.0.6 den Text ab der ersten Position eines Sonderzeichens ab. Das zerhaut uns nicht nur unser Layout, sondern wir müssen nun lang und breit eine Lösung suchen.

Nachtrag von 13:30 Uhr:

So, wir haben uns den aktuellen Stand der Version 6.0.0.7 aus dem SVN gezogen, in dieser Version wurde nun der Umlautefehler behoben. Ein kurzer Test ergab, dass dies auch wirklich stimmt. Dann kann die Arbeit ja weitergehen …

Nachtrag vom 05.11.2009 09:26 Uhr:

Im trunk des SVN liegt eine neue Datei, die genau dieses Problem nun löst, die Datei heißt:

/webEdition/we/include/we_editors/we_editor_script.inc.php

und es handelt sich um die Revision 1409.

Mit Hilfe dieser war es uns nun möglich, den Editor wieder in Betrieb zu nehmen. Ein Hinweis noch: In webkit-basierten Browsern – wie Chrome, Iron, Safari, usw. – macht der Editor probleme. Es ist nicht möglich, die Schriftgröße zu ändern. Sobald man das entsprechende Feld anklickt, wird der selektierte Text auf maximalgröße gesetzt und läßt sich auch dannach nicht mehr ändern.

Aber immerhin funktioniert nun soweit alles im IE und FF, dass man damit etwas besser arbeiten kann.

Google aktualisiert Chrome auf Version 3

Ab und zu benutze ich Google´s Chrome Browser. Ich finde diesen Browser recht gut, vor allem schnell. Leider fehlt mir – um komplett zu wechseln – die möglichkeit, Add-On´s zu installieren. Ich brauche, berufsbedingt, solche Sachen wie Firebug und co., um vernünftig und effektiv arbeiten zu können. Gut, bei Chrome heißen die Add-On´s Extensions und kommen irgendwann mit Version 3.

Nun, gestern meine Überraschung. Ich starte Chrome, alles okay. Ich surfe etwas, mache Chrome kurz dannach wieder aus. Surfe noch was mit Firefox, mache dann Chrome wieder an und siehe da: Die Seite “Neuer Tab” sieht schon ganz anders aus. Ein Blick in die Info und siehe da: Chrome Version 3.0.195.21. Cool, die Version 3 ist aus dem Beta und mittlerweile stable, sehr schön.

Kleiner Test mit den Extensions, aber: Funktioniert immer noch nicht, weil deaktiviert. Gut, warte ich noch eine Weile, aber Firefox lebt mittlerweile echt gefährlich.

Ein wenig hoffe ich auch darauf, dass Mozilla sowas wie Memory Management und schnelleres Startverhalten noch in eines der nächsten Releases hinbekommt. Firefox ist toll zum arbeiten, Chrome sehr gut zum surfen auf JavaScript-lastigen Seiten – zum Beispiel in Browsergames.

Schauen wir mal, was die Zukunft bringt.

Kleiner Randbeitrag: SR Ware´s Iron Browser – Chrome ohne Google sozusagen – ist ebenfalls in Version 3.0.197.0 erschienen. Beim Iron sind aber die Extension aktiviert. Leider funktioniert schon das Google eigene GMail-Checker nicht richtig, auch an dieser Baustelle (Iron Browser) muss ich also noch was warten.

SQL-Injection sichere MySQL-Query Funktion

Immer wieder ein Thema: SQL-Injections in Webseiten. Nicht zuletzt, seit es immer mehr große Zeitschriften sich zum Thema machen, das Prinzip ‚Wie führe ich eine SQL-Injection durch‘ auch für die ganz … naja, sagen wir mal lernfaulen … auf zu schreiben, wird das Thema doch immer beliebter.

Deshalb stelle ich nun mal – im kleinen Rahmen natürlich – meine Funktion vor, mit deren Hilfe es mir gelang, meine Projekte bis dato SQL-Injection safe laufen zu lassen.

Die Funktion, wie ich sie hier vorstelle, ist nur ein Auszug aus der echten Funktion. Die Funktion selbst liegt bei mir auch innerhalb einer Klasse. Abgerundet mit vielen Features – wie z.B. logging der SQL-Strings, logging der Dauer einzelner und aller Abfragen usw., hat mir diese Klasse über die Jahre sehr gute Dienste geleistet, was eine schnelle, saubere und vor allem sichere Erstellung von Webprojekten angeht.

Okay, genug geschwafelt, hier der Code:

public function myquery()
{
   $args    = func_get_args();
   $query   = array_shift($args);
   $args    = array_map(‚mysql_real_escape_string‘, $args);
   // echo vsprintf($query, $args).“
\n“;
   return mysql_query(vsprintf($query, $args));
}
 

Der Experte sieht gleich, was hier passiert, allen anderen erkläre ich es gern. Die Funktion nimmt sich alle Argumente, benutzt das erste Argument als SQL-Query-String und alle folgenden als Argumente zu diesem String. Alle Argumente werden mit der Funktion mysql_real_escape_string behandelt, welche alle für mySQL gefährlichen Zeichen entsprechend ungefährlich macht (mal salopp ausgedrückt).

Dannach werden die Argumente mittels printf-Funktion in den Query gebracht und dann wird das ganze ausgeführt. Zurück bekommt ihr den Rückgabewert von mysql_query, mit dem ihr dann ganz normal weiterarbeiten könnt.

Ein Beispiel-Aufruf:

$sql = „SELECT userid FROM tblUser WHERE username=’%s‘ AND password=MD5(‚%s‘)“;
$_ressource = mysql_query_safe($sql,$_POST[„username“],$_POST[„password“]);

Hier wird – in einer sonst sehr gefährlichen Umgebung – die UserID nach einem Login anhand von Username und Passwort ermittelt, die der User eingegeben hat.

Die einzelnen Tags, also wann kommt ein %s, wann ein %u usw., das lest ihr am besten direkt bei der Funktion sprintf nach.

Verbesserungsvorschläge nehme ich natürlich gern entgegen.

Dynamische Daten mit jQuery in eine Textarea schreiben

Beim Versuch, dynamisch nachgeladene Daten in eine Textarea schreiben zu wollen, bin ich auf eine besonderheit der textarea hereingefallen.
Normal funkioniert es ja mit z.B. einem so

$(’span#meinspan‘).html(meinedaten);

Alternativ natürlich auch mit .text.

Okay, nun wollte ich Daten in eine Textarea schreiben:

$(‚textarea#meineta‘).html(meinedaten);

Aber die TA blieb leer. Firebug zeigt zwar an, dass der Inhalt von ‚meinedaten‘ korrekt platziert ist, er wird aber nicht angezeigt. Nanu?

Dann komme ich doch drauf: Die TA wird als Formularfeld behandelt, und alle Formfelder werden nicht mit .html sondern mit .val gesetzt, also so

$(‚textarea#meineta‘).val(meinedaten);

Nun zeigt der Browser alles korrekt an.

Ich habe zwar schon vorher Form-Felder mit val gefüllt, kam aber in bezug auf die TA nicht auf diese Lösung,da ja in einem die Werte in value=““ bereichen stehen, in der TA aber zwischen dem öffnenden und dem schließenden Tag, also käme dort ja das .html richtig.
Naja, Spezialfall eben, merkt es euch und nicht in diese Falle laufen 😉

Import von großen mySQL-Dumps

Ich habe hier einen mySQL Dump der Größe 173 MB.
Das ist wirklich eine Menge.
Dazu kommt, dass es Zeilen gibt, die über 1 Mio Zeichen lang sind. Dies sind INSERT INTO Kommandos, die direkt auf einer Zeile 10.000 Datensätze importieren (siehe Doku zu INSERT INTO). Hauptproblem an der Sache war, dass es phpMyAdmin nicht hinbekam, die Datei
a) hochzuladen
b) zu verarbeiten
Auch der mySQL Query Browser flog mir bei der Menge von Daten einfach mal davon.

Außerdem: Es muss doch einen einfachen Weg geben, die ganzen Daten problemfrei auf einen Rutsch zu importieren. Gesucht, gelesen, getan.

Die Lösung: Man öffne die Kommandozeile und gehe zum Verzeichnis der mySQL Installation. Man benötigt das ‘mysql’ Programm, dies liegt meist im ‘bin’ Verzeichnis der Installation.

Nun benutzt man folgendes Kommando:

mysql –u [USERNAME] –p[PASSWORT] [DATENBANKNAME] < [SQLDATEI]
  • [USERNAME] = Dein Username, z.b. root
  • [PASSWORT] = Klar, oder? Bitte KEIN Leerzeichen zwischen –p und dem Passwort. Wenn ihr einen Account ohne PW habt, dann einfach nix hinschreiben.
  • [DATENBANKNAME] = Die DB muss existieren, dann einfach hier angeben.
  • [SQLDATEI] = Voller Pfad zur SQL Datei

Beispiel: mysql –u sascha –pMeinPW SaschasDatenbank < “c:/sqldumps/meinedatenbank.sql”

Einmal ENTER drücken und warten. Meine 173 MB waren in sagenhaften 30 sek. importiert, komplett und ohne Fehler. *wow*

Viel Erfolg weiterhin …