eBesucher verbietet NoScript-Addon

Mein Besuchertausch „eBesucher“ verbietet seit neuestem das Firefox AddOn „NoScript„.
Da dies m.E. nicht recht so sein kann, da ja immerhin viele eBesucher Seiten ziemlich … naja … lästigen Code enthalten (Framebrecher, Cookie-Räuber, Malware-Meldungen, usw.) habe ich das ganze mal mit „Firebug“ gedubbed und hier die Lösung zum Problem.

  • Rechtsklick auf das NoScript „S“ im Statusbereich, dann auf „Einstellungen“
  • Dort auf den Reiter „Plug-ins“ und dort den Haken bei „ verbieten“ rausmachen.
  • Dann mit OK bestätigen.

Das Prototype-Javascript-Script prüft nur nach, ob die IFrames geblockt werden, in dem geprüft wird, ob der entsprechene NoScript-Platzhalter gesetzt ist („__noscript_placeholder__“). Dieser wird nur gesetzt, wenn diese Option aktiviert ist.
Macht man den Hacken raus, kann man NoScript weiterhin mit eBesucher ganz normal benutzen.

Alternativ kann man auch die Lösung von Daniel Roß benutzen, die lediglich den Platzhalter entfernt, was die Zielseite erst gar nicht lädt. Zu finden ist die Anleitung im Blog von Daniel.

Eine JS-Prüfung auf ein installieres AddOn im Firefox ist AFAIK nicht möglich.

Auch Profis machen Fehler *grins*

Ich wühle mich durch die Dokumentation zu den we-Tags von webEdition. Dabei fiel mir auf, dass auch gestandene Profis im Webbereich Fehler machen, die diese eigentlich nicht machen dürften.

Ein Beispiel aus der Doku zum we-Tag “we:keywords”:

Mit htmlspecialchars=“true“ werden Sonderzeichen in HTML-Entities umgewandelt (z.B. wird „&“ zu „&“). Ist htmlspecialchars nicht gesetzt, wird diese Umwandlung nicht vorgenommen.

Sicherlich ist gemeint, dass ein & zu einem & wird, aber da hat wohl der Editor dem Autor einen Streich gespielt und das & nicht richtig “escaped” und der Browser stellt das & (ganz korrekt übrigens) als & dar.

Also, liebe Profis bei webEdition, durchcrawled mal eure Doku und korrigiert dies bitte, damit auch Amateure den Mehrwert des Attributes “htmlspecialchars=true” kennenlernen dürfen.

Irgendwie bin aber doch beruhigt, dass sowas auch anderen passiert, sind also doch alles auch nur Menschen am anderen Ende der Doku *wink*

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 …

jQuery, bitte helfen Sie … nicht!

Wer bei jQuery ein Support Ticket aufgibt oder einen Bug via Trac meldet, dem sollte klar sein, dass die Menschen dort nicht gerade die nettesten sind, genauer gesagt sieht es so aus, als wäre z.B. ein gewisser „scott.gonzalez“ ein recht schroffer und unfreundlicher Typ.

Ich dachte einst, ich hätte einen Fehler in jQuery gefunden und meldete diesen auch. Ich beschrieb das Problem und lieferte Sourcecode mit, natürlich nur einen Teil (das nötigste) und auch mit anderen Funktionsnamen. Dabei können einem durchaus Fehler passieren, nicht aber „scott.gonzalez“, der ist nä(h)mlich perfekt, wie es scheint.
In meiner Beschreibung – genauer gesagt im Sourcecode – hatte sich ein Schreibfehler eingeschlichen.
Ich schrieb:

$(document).ready(function()
{
// Add some dynamic content here
$(‚div#mydiv‘).html(‚myLink“>Click me!‘);

// Try to make some event with it…
$(‚a#mylink‘).click(function(){
console.log(‚Hello World…‘);
});
};

Die betreffende Stelle habe ich mal hervorgehoben. Ich schrieb oben „myLink„, unten jedoch – Asche auf mein Haupt – nur „mylink„, also einmal großes L, einmal kleines l.
Das dies ein simpler Vertipper sein kann sollte eigentlich jemanden klar sein, der Support leistet. Aber „scott.gonzalez“ – mein Bearbeiter bei jQuery – ist da stur wie ein Roboter. Anstatt sowas zu sagen wie

„Hey, du hast da einen Tippfehler drin, kleines l statt großem L, aber ich gehe mal davon aus, dass das nicht das eigentlich Problem ist. Wenn ich da nämlich ein großes L reinmache sehe ich, dass es immer noch nicht geht und das liegt daran: ….“

Cool – wie „scott.gonzalez“ nun mal ist – schließt dieser das Supportticket und schreib kurz und knapp:

„Ids are case sensitive, you need to use ‚#myLink‘ not ‚#mylink‘.

Closing invalid; this has nothing to do with jQuery UI.“

Und damit ist der Fall erledigt.
Danke für den tollen Support…

Automatische Aktualisierungen mit jQuery

Wer mit jQuery arbeitet, der baut sich schnell viele Funktionen, die die Arbeit erleichtern sollen. Leider fehlt jQuery sowas wie ein Timer, der bestimmte Funktionen immer wieder aufruft … der JavaScript Erfahrene Entwickler weiß genau: „Da nehme ich doch setInterval()„.

Genau, und mit setInterval() kann ich auch jQuery Funktionen aufrufen.
Habe ich beispielsweise eine jQuery-Funktion zum AJAX nachladen von Daten wie

jQuery.fn.loadSomething = function()
{
…..// mach was, z.B. einen AJAX-POST oder sowas…
}

dann kann ich in in meiner ready Funktion sowas hier schreiben:

$(document).ready(function()
{
…..setInterval(„$(this).loadSomething();“,30000);
});

Das ruft mir nun alle 30 sekunden meine jQuery-Funktion loadSomething auf, in der ich allerhand Schabernack treiben kann.

Sehr praktisch…