Anführungszeichen werden automatisch maskiert

Hab damit keine Probleme, dass du dafür FULL-HTMl nehmen solltest, hast du aber hscon richtig entdeckt, weil IDs und Classen in Filtered nur bei a-Tags gehen.

Wenn du HTML eingibst, benutzt du aber kein WYSIWYG Editor oder?

----------------------------------------

http://tobiasbaehr.de/
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Ein Forum ist kein Ersatz für das www (Google.de).

Nö, ich hab was ganz einfaches geschrieben in Notepad++. Sind nur ein h2-tag und ein paar divs, die mit Classen/IDs ausgewiesen sind. Das hab ich dann so wie es ist bei Drupal reinkopiert.

Mir ist aufgefallen, dass Drupal die Anführungszeichen richtig einsetzt, wenn ich diese weglasse und einfach nur class=classname schreibe. Funktioniert aber nicht wenn URLs im Spiel sind oder wenn ich mehre Classen vergeben will (class="classname1 classname2 classname3"). Dann kapiert er's nicht mehr. Und eine wirklich gute Lösung ist das wahrscheinlich eh nicht.

Hängt das irgendwie mit der Konvertierung (UTF-8 oder so) zusammen? Kenne mich da zwar nicht besonders aus, aber Zeichenfehler hatte ich auch mit anderen Anwendungen deswegen schon öfters.

An der Konfiguration vom "Full HTML" scheint es anscheinend wirklich nicht zu liegen. Ich glaube ich hab inzwischen so ziemlich alle Möglichkeiten durchprobiert. Stimmt da also doch irgendwas mit meiner Installation nicht...?

Sorry wegen Doppelpost...

Nico

Trotzdem nochmal explizit die Frage: Benutzt du einen WYSIWYG-Editor? Die meinen es oft zu gut und escapen Dinge, mit denen Drupal selbst sehr gut zurechtkommt.

ciao, Ronald

Ne tu ich nicht. Hab ja oben geschrieben, dass das ein paar Zeilen handgeschriebenes HTML sind (Notepad++) und das kopier ich dann in Drupal. WYSIWYG ist eigentlich nicht im Spiel.

So speicher ich die Sache ab: http://www.bildercache.de/anzeige.html?dateiname=20090811-151916-442.png
Und das kommt bei raus wenn ich nochmal drauf gehe: http://www.bildercache.de/anzeige.html?dateiname=20090811-152301-69.png

Wie ich sehe, ist der Eingabefilter "Full HTML" einigermaßen frisiert. Versuch mal folgende Gegenprobe: Leg ein neues Eingabeformat an und schalte darin KEINEN Filter ein. Versuch mal, damit deine Seite abzuspeichern. Und nochwas: werden die Zeichen auch escaped, wenn du sie direkt im Browser tippst?

ciao, Ronald

Hab wie beschrieben einen neuen Eingabefilter angelegt und nichts angekreuzt, aber immer noch mit dem selben Ergebnis.

Vorher: http://www.bildercache.de/anzeige.html?dateiname=20090811-153843-75.png
Nachher: http://www.bildercache.de/anzeige.html?dateiname=20090811-153827-445.png
Browserausgabe: http://www.bildercache.de/anzeige.html?dateiname=20090811-153804-571.png

Jap!

Scheiße, selbes Problem auch bei Contemplate, hab mir gerade nen Inhaltstyp versaut...
Ist aber wohl was neueres, das hat vorher ohne Probleme funktioniert.

Also so aus der Ferne bin ich damit am Ende meines Lateins. Hast du spaßeshalber mal einen anderen Browser versucht, einem anderen Theme? Manchmal sind es Dinge, die sich mit normaler Logik nicht erschließen. ;-)

ciao, Ronald

Browser und Theme sind's auch nicht.
Was kann ich denn jetzt noch versuchen? Module nach und nach deaktivieren? Hab eigentlich nichts neues installiert, nur vielleicht ein paar Updates...

// Hab alle nicht-Core-Module deaktiviert, hat aber auch nichts gebracht.
/// OK, also wenn ich direkt in die Tabelle gehe mit PhpMyAdmin geht's. Ist zwar umständlich, aber ich kann immerhin weiterarbeiten...

... bei einer automatischen Drupal-Installation auf einem All-inkl-Testserver.

Da ich vorher so etwas noch nie gesehen habe, nehme ich mal an, dass das evtl. ein Anti-SQL-Injection-Feature von All-inkl. ist oder dass das durch irgendein serverseitiges Filtering auf mod-security-Ebene passiert. Wie gesagt: auf einem Testserver; vielleicht war's das ja. Werde das selber aber wohl nicht weiter verfolgen ...

Oh OK, das ist ja interessant! Meine Seite läuft auch bei einem All-inkl-Paket. Werde mich dann wohl demnächst mal an den Support wenden, vielleicht haben die ja eine Lösung parat.

Danke!

Berichte mal bitte, was die sagen.

Super, bei mir ist das Problem gelöst. Das hat all-inkl dazu gesagt:

Funktioniert perfekt wie beschrieben. Die genannte Zeile kommt in meiner .htaccess dreimal vor.

All-inkl rules 8)

Ja, das funktioniert, erklärt es aber noch nicht. Denn jede Drupal-.htaccess-Datei deaktiviert magic_quotes_gpc mit den Anweisungen für jeweilige PHP-Versionen. Das heißt, das steht da immer dreimal drinnen und ist ganz normal.

Das empfohlene Auskommentieren bewirkt, dass magic_quotes_qpc wieder auf "On" steht, das heißt, Du hast in Wahrheit die automatische Sonderzeichen-Maskierung wieder eingeschaltet.

Jetzt kommts: Drupal verläßt sich nicht auf die seine versuchte Einstellung in der .htaccess, sondern checkt beim Bootstrap, ob wirklich magic_quotes_qpc off-geschaltet ist. Wenn nicht, dann demaskiert Drupal eigenständig! Das heißt zu deutsch: wenn man die Maskierung abschaltet bei All-Inkl, dann maskiert etwas Seltsames und Nichtoffensichtliches (evtl. MySQL?) im Hintergrund dennoch. Wohl ein Sicherheits-Feature?!

Aber Drupal macht das auch und schiebt seine fix_gpc_magic-Funktion immer dann dazwischen, wenn magic_quotes_gpc auf ON steht und verläßt sich also nicht auf die eigene .htaccess. Drupal rules 8)

Daher muss offenbar bei All-inkl magic_quotes_gpc für Drupal eingeschaltet sein. Sinnvoll ist das ja nicht und auch kein Performance-Feature: PHP fügt magic quotes hinzu und Drupal entfernt sie wieder - es wäre schon besser, wenn sie im Falle Drupal's PHP-seitig von vornherein abgeschaltet wären, dann würde auch Drupal's fix_gpc_magic-Funktion nicht laufen müssen.

Da haben sich also zwei Sicherheitskonzepte überlagert. Aber aus Performance-Gründen wird es diese Einstellung ab PHP 6 sowieso nicht mehr geben.

OK, das war dann wohl die ausführlichere Antwort - danke!

Aber ich sehe es richtig, dass die Lösung so wie ich es jetzt habe keine Probleme verursacht, richtig?

Nö, Probleme macht das so nicht.
Es ist natürlich unbequem, weil Du bei Drupal-Updates auf Deine .htaccess aufpassen musst. Ich lege in solchen Fällen meist eine Datei namens !!_htaccess_Aenderungen_!! ins Installationsverz., worin die Änderungen vermerkt sind. So muss ich bei Updates nicht Zeile für Zeile vergleichen, sondern weiß nach einem Blick in diese Datei, welche Änderungen nach dem Update gemacht werden müssen.

Security-EDIT: So eine Datei aber besser .htaccess_!!_Aenderungen o. ä. benennen, jedenfalls sollte sie beginnend mit .ht (Punkt-"h"-"t") benannt werden. Somit ist die Datei i. d. R. gegen Blicke von Zaungästen, die hier lesen und die Datei evtl. direkt aufrufen wollen, geschützt. (Testen!!) Im Idealfall sollte ein "Forbidden" herauskommen, wenn man die URL einer Reminder-Datei aufruft.

Ah OK, das muss also nach jedem Update überprüft werden - gut zu wissen.
Werde mir dann wie du gesagt eine Datei anlegen mit allen Änderungen. Is ja keine große Sache.

Danke für deine Hilfe!

Nach meiner Beobachtung ist das alles jetzt nicht mehr nötig: bei mir funktioniert es auf einem All-inkl-Server nun überraschend auch mit dem standardmäßigen "php_value magic_quotes_gpc 0", ohne dass da automatisch und dennoch maskiert wird. Daher könnte jetzt evtl. die manuelle Nacharbeitung der .htaccess nicht mehr nötig sein. Vielleicht ist da also von All-inkl inzwischen an den generellen Einstellungen gebastelt worden...

Falls das jmd. bestätigen kann, bitte posten.

Ich habe das selbe Problem bei Drupal 7 auch, allerdings sieht hier die .htaccess wohl anders aus, da ich die erwähnte Zeile "php_value magic_quotes_gpc" nicht finden konnte. Und ein Auskommentieren der vorhandenen Zeile "php_flag magic_quotes_gpc" hat zu nichts geführt (war auf "off").

Hat jemand schon Erfahrungen mit diesem Problem in Drupal7 gemacht und eine Lösung dafür, bevor ich dem Provider versuche klarzumachen, was ich brauche?

LG, Xantha