Článek v rubrikách:
Zpětně lomítko \ \ a FCKeditor nebo jak používat zpětné lomítko, když je výstup formuláře v nějaké fázi ošetřen pomocí příkazu stripslashes
Typicky vstupy do databáze jsou ošetřeny příkazem addslashes a výstupy pak naopak příkazem stripslashes, ale co když tam to zpětné lomítko opravdu chceme? Stejně se chová FCKeditor při přepínání mezi zdrojovým kódem a wysiwyg.
Pro případy ošetření výstupu formulářů postačí pro chtěná zpětná lomítka používat html entitu, tedy \. Pak nebude zobrazení lomítka ohroženo běžnými operacemi s textem, které se provádí před a po ukládání textu do databáze.
Jiný problém je s FCKeditorem, který defaultně tuto html entitu nahrazuje za zpětné lomítko, je potřeba vyřadit tuto html entitu ze zpracování FCKeditoru.
Musíme editovat soubor fckconfig.js v kořenovém adresáři instalace FCKeditoru. Potřebujeme přidat příkaz s touto syntaxí FCKConfig.ProtectedSource.Add(/\/);, nevýhodou je, že zpětné lomítko nebude vidět ve WYSIWYG módu. Přidávat musíme zpětné lomítko do zdroje textu, jinak WYSIWYG mód převede \ na \, nebude to pak html entita zpětného lomítka.
Dosud jsem lepší způsob nenašel, pokud najdu určitě se podělím.
komentáře
RSS Komentáře
Rozebíralo se to třeba na http://php.vrana.cz/…otes_gpc.php#…
popravdě když teď zpětně čtu co jsem tehdy psal, tak se divím proč tam píši o stripslashes, když tak jsem výstup z dtb nikdy neošetřil tímto způsobem, právě kvůli tomu co říkáš, ale už jsem doma, jedná se právě o ten fckeditor, kde doporučují použití stripslashes v kombinaci s magic_quotes, tedy pokud máte zapnuté magic_quotes bude používat stripslahes pro předávání hodnot fckeditoru, v opačném případě stripslashes není vhodné použít



Pokud data ošetříme funkcí addslashes (a není použita direktiva magic_quotes_gpc), tak jsou uvnitř databáze v čisté podobě. Ošetřit je na výstupu funkcí stripslashes je tedy chyba, protože sežere lomítka, která by v textu měla zůstat.