Seite 1 von 1
include.str_overview.php/HTML-Tags in Kategoriebez.
Verfasst: Do 12. Mai 2005, 10:21
von calvini
Probleme dieser Art werden mit Sicherheit noch an vielen anderen Stellen auftreten - Bei uns hat ein Redakteur HTML-Tags in Kategorie-Bezeichner eingetragen und wo er gerade mal dabei war, auch ein bißchen damit rumprobiert. Resultat war, dass die Anzeige im Kategorie-Editor zerschossen wurde. Ich schlage deshalb folgende 2 Änderungen in include.str_overview.php vor:
Ändere (ca. Zeile 255)
Code: Alles auswählen
<td class="text_medium"><input class="text_medium" type="text" name="newcategoryname" value="'.$value->name.'"></td>
in
Code: Alles auswählen
<td class="text_medium"><input class="text_medium" type="text" name="newcategoryname" value="'.htmlspecialchars($value->name).'"></td>
und optional noch (ca. Zeile 241)
in
Code: Alles auswählen
$tpl->set('d', 'CATEGORY', strip_tags($value->name));
Wenn man schon da ist, könnte man ziemlich genau in der Mitte dazwischen auch noch
in
ändern.
Oder natürlich ersatzweise HTML-Tags in Kategoriebezeichnern verbieten (d.h. vor dem Speichern entfernen). Ich persönlich würde aber obige Lösung bevorzugen.
Verfasst: Do 12. Mai 2005, 13:40
von HerrB
Es wird mit ziemlicher Sicherheit für die V4.4.x-Serie keine Korrekturen mehr geben. Bitte kontrolliere, ob das Problem auch in der CVS-Version noch besteht und trage entsprechende Probleme oder Änderungsvorschläge bei Bugs V4.5 ein.
Solltest Du bestätigen, dass sich im Verhalten an dieser Stelle im CVS nichts geändert hat, verschiebe ich den Post nach Bugs V4.5.
Gruß
HerrB
Verfasst: Do 12. Mai 2005, 13:54
von calvini
HerrB hat geschrieben:Bitte kontrolliere, ob das Problem auch in der CVS-Version noch besteht und trage entsprechende Probleme oder Änderungsvorschläge bei Bugs V4.5 ein.
Solltest Du bestätigen, dass sich im Verhalten an dieser Stelle im CVS nichts geändert hat, verschiebe ich den Post nach Bugs V4.5.
Mich jetzt noch mit CVS-Versionen und der 4.5 zu beschäftigen, würde den Zeitrahmen sprengen. Ich habe gerade nochmal 4 Tage Zeit, das System so narrensicher zu machen, dass unsere Leute hier während meines Urlaubs keinen größeren Schaden anrichten können. Nach meinem Urlaub werde ich mich dann auch mal mit den CVS-Version bzw. 4.5 befassen.
Heißt das, ich kann eventuelle weitere (mögliche) Fehler in der 4.4.5 einfach still und heimlich bei mir beheben und soll sie hier nicht mehr posten?
Verfasst: Do 12. Mai 2005, 14:07
von emergence
calvini hat geschrieben:Heißt das, ich kann eventuelle weitere (mögliche) Fehler in der 4.4.5 einfach still und heimlich bei mir beheben und soll sie hier nicht mehr posten?
nein, es bedeutet nur das nicht sicher ist ob diese bugs in der 4.4.x serie noch behoben werden... andererseits sind manche dieser bugs bereits im cvs_head behoben worden...
die oben angeführten code zeilen existieren in dieser form nicht in
include.con_str_overview.php (auch nicht im contenido-cvs-2005-04-29.tar)
ähm sicher das du nicht ne andere datei gemeint hast ?
vielleicht diese da -> include.str_overview.php
da gebe es die entsprechenden code zeilen... sowohl 4.4.x als auch cvs_head
ein verschieben nach bugs 4.5.x soll timo entscheiden, da es auf beide versionen zutrifft...
Verfasst: Do 12. Mai 2005, 14:53
von calvini
emergence hat geschrieben:ähm sicher das du nicht ne andere datei gemeint hast ?
vielleicht diese da -> include.str_overview.php
Jepp - wird echt Zeit, dass ich in den Urlaub komme. Bin beim Suchen im Forum auf einen anderen Fehler gestoßen, habe den Titel kopiert und dabei nicht gemerkt, dass der Dateiname leicht variiert, sorry. Wäre wohl am Besten, wenn jemand mit Datenbankzugriff den Titel dieses Threads entsprechend anpasst
.
Verfasst: Do 12. Mai 2005, 14:56
von HerrB
Heißt das, ich kann eventuelle weitere (mögliche) Fehler in der 4.4.5 einfach still und heimlich bei mir beheben und soll sie hier nicht mehr posten?
Nein, es wäre halt nur schön, wenn man sich noch die Mühe macht, auch gleich im CVS-Code nachzusehen.
Gruß
HerrB
Verfasst: Do 12. Mai 2005, 14:58
von emergence
@calvini
hab ich soeben im ersten posting geändert...
mittels edit button neben dem beitrag kann jeder forumteilnehmer seine eigenen postings nachmodifizieren...
Verfasst: Do 12. Mai 2005, 15:06
von calvini
HerrB hat geschrieben:Nein, es wäre halt nur schön, wenn man sich noch die Mühe macht, auch gleich im CVS-Code nachzusehen.
O.k., nachgucken kann ich
- hab mir mal nen Link auf das
CVS-Verzeichnis gespeichert. Womit entpacke ich *.bz2-Dateien auf Fenster-Systemen?
emergence hat geschrieben:@calvini
hab ich soeben im ersten posting geändert...
mittels edit button neben dem beitrag kann jeder forumteilnehmer seine eigenen postings nachmodifizieren...
Sollte man als Besitzer eines eigenen Forums eigentlich wissen
, wenn man mal nachdenkt, ist es klar, dass man damit auch den Titel ändern kann - Danke
.
Verfasst: Do 12. Mai 2005, 15:14
von HerrB
Womit entpacke ich *.bz2-Dateien auf Fenster-Systemen?
Auf Fenster kommen sie als .tar an - mit WinRAR, z.B.
Gruß
HerrB
Verfasst: Di 31. Mai 2005, 16:23
von timo
Ich habe mir das ganze noch etwas angesehen und muß leider sagen: Ist alles nicht so einfach.
Im Prinzip sollte bei folgendem Beispiel bei der Eingabe im Kategoriebaum folgendes passieren:
- Der Redakteur gibt <b>hällö</b> ein.
Derzeit kommt
hällö heraus.
Wird ein strip_tags eingesetzt, so wird nur hällö ausgegeben (wünschenswert wären hier die Tags). Wird ein htmlspecialchars eingesetzt, so bekommt man im Kategorienbaum <b>hällö</b> heraus, was richtig wäre, aber nur dann korrekt funktioniert, wenn man Umlaute auch wirklich nur im selben Encoding speichert (diese werden dann nicht mit ä in der DB gespeichert). Nimmt man ein anderes Encoding, wandelt der Browser es in Unicode im, d.h. man erhält dann
<b>h{</b> oder ähnliches zurück...
Ich habe erstmal ein htmlspecialchars eingebaut, was ich richtiger finde als z.b. die HTML-Tags zu strippen, aber darüber können wir ja noch diskutieren