wp_editor автоматом заменяет html

То есть все сделано через жэпе в вашем фреймворке.

Нормально делается вот так: в бд пишется как есть, а на выводе стоят санитары в формате тех самых htmlentities() или там strip_tags() или да, htmlspecialchars().

Насколько я помню - это делает tinymce.

А на будущее тебе может сгодиться этот ман. Мб как старт для дальнейшего изучения темы ;).

Ох уж эти "крутые" дизайнеры... Когда они уже прекратят лезть в вещи, в которых совершено не понимают. И я совсем не ВП имею ввиду.

Конечно ВП тут не стоял, например этот скрипт так и делает - в бд пишет как есть, а выдает через санитарную машинку как все нормальные скрипты делают, аксиоматически. Экран sql-букавок это не то же самое.

Когда ты уже со своими аксиоматическими выводами будешь дизайнерить и прекратишь лезть в непонимаемые тобой области?

Если по предмету, то возможно и так и эдак. Причём одновременно.

Так мне надо знать про эти области. Вы бы объяснили в качестве хорошего начала.

---------- Добавлено 05.08.2015 в 19:57 ----------

Идея корежить хтмл перед записью в БД рождается в головах тех программистов, которые не различают клиента и сервер, браузер и базу данных. Им все это кажется заедино и страшилки про инъекции толкают на порчу аутентичности текстов.

Так вот базам данным по барабану вся эта хтмльная разметка, для драйвера бд - хтмл - такой же текст, как любой другой, который экранируется на спец-символы самого языка. Более того, вообще всем программам способным читать текст - хтмл по барабану. Единственная программа которой он грозит - браузер. Следовательно обычная логика подсказывает что в браузер надо выдавать проверенный хтмл не разбираясь откуда он появился - из админки или с публичного канала.

Потому что если полагаться на проверенный хтмл полученный из бд, то запросто пропустить непроверенный из файла, например из файла сессии, из файла куков или еще откуда-то. Так и получится тогда, что придется одновременно проверять и туда и обратно, каждый раз вникая что там должно быть, то есть расходуя ресурсы понапрасну и усложняя коды.

Кроме того работать с дампом бд станет практически невозможно. Все эти энтитьки делают текст абсолютно нечитабельным. Конечно такое случается редко, но когда случится вы сразу поймете что лучше.

Короче, есть инженерный подход - завести 0, базу, точку отсчета - и плясать от нее. В потоках текста такой точкой считается аксиома: пишется как есть, читается с преобразованием.

---------- Добавлено 05.08.2015 в 20:05 ----------

Кстати, чтобы js мог нормально распихивать данные полученные от сервера по input'ам формы, нужна функция декодирования ентитек в теги. Потому что сервер тупо выдает преобразованное в расчете на браузер, а когда эти ентитьки получает скрипт, он их так и засунет и получится бнопня. Да, можно отпарсить силами браузера, но опять же это опасно, поскольку там может быть <script> и браузер тупо его выполнит как только отпарсит. Функция декодирования есть в инете, но там список голимый, я его сократил, enjoy:

var html_entity_decode=function(str) {
	var m={"194":"¿","195":"ÿ","197":"Ÿ","198":"ƒ","203":"˜","206":"ο","207":"ϖ","226":"♦","38":"&","34":""","39":"***039;","60":"<","62":">"},d=0;
	for(d in m)
		str=str.split(m[d]).join(String.fromCharCode(d));
	return str;
};

Экранировать надо в запросе, а в бд символы экранирования уберутся.

Нивапрос. Но вкратце.

1. Из БД со временем может запросится новым/изменённым или даже чужим скриптом (сделанным на заказ). Что и как там будет - вопрос. Для пущей уверенности, что из БД не вылезет зараза - эту заразу для начала нужно не пустить в БД.

2. Преобразование на лету - это доп. нагрузка. Причем мб не малая.

3. История с магическими кавычками и синтаксиса пхп (<? / <?php) - как пример независимых от юзера проблем.

Разжевать?

ЗЫ. Просьба/совет - употребляй меньше аллегорий и самопридуманных слов, а то тебя порой непросто понять.

1. Так не бывает. Любой грамотный программист четко знает чем может грозить дамп БД в браузер. А кто не знает - это его проблемы.

2. Вы ее никогда не видели, но пишите как будто она есть - нагрузка. Ну ладно, сколько секунд занимает миллион преобразований текста в 1кб? (не говоря про банальное кеширование).

3. Это надо разжевать, да. Смутно помню преданья старины глубокой, с этой магией, так чем там все закончилось?

---------- Добавлено 06.08.2015 в 16:21 ----------

Для тех кто попкорна набрал полное ведро: это вопрос не техники, но культуры. Техника тут чисто реализация, а принципиальное решение вытекает из культурного уровня, важность которого нельзя переоценить. Фундаментально невозможно создать дуракоустойчивую БД. Любая девачко запузырит вам 10 раз одного и того же - товара, клиента, пациента - просто потому что у нее нет культуры задать вопрос: а вы раньше обращались, или поискать что уже было похожего внесено в бд, ну и в таком роде. Культура хранения данных лишь продолжение этой культуры проектирования и пользования реляционными БД. Которые, сами понимаете, ну никакого отношения не имеют к сраным браузерам и рвотному хтмлю.

Ну при чем тут хтмл и база данных? Ну где тут вообще связь чтобы иметь хоть какое-то основание для пункта 1?

Потому что бд приспособили для выдачи в браузер? - Так это частный случай, не более того.

Похоже, это вы её не видели, и думаете, что это просто игра слов. Почитайте какие-нибудь топики по шаблонизаторам, (XSLT vs Twig vs ... ). Преобразование на лету так или иначе даёт нагрузку. Величина её может быть небольшой, и может быть очень большой. На посещаемом сайте это очень чувствительно. А по поводу "банального кэширования" - это лекарство не всегда помогает, и принимать его тоже надо уметь.

Если есть возможность обработать контент ПЕРЕД тем как поместить его в базу, это нужно сделать обязательно, а контент, содержащий признаки вредоносности не надо отправлять в базу вообще. Никто не мешает править контент ПОСЛЕ, если на то есть веские причины. Но, алгоритмы-то будут применены всё те же, так зачем как вы выражаетесь "санитизировать" контент каждый раз при открытии странички, когда это можно сделать один раз.

Да я все понимаю что для вас бд и веб - одно слово. А для тех кто понимает что это разные слова и вообще хоть немного озабочен культурой пользования баз данных, тот сохраняет аутентичность, а слабоумному браузеру отдает то, что его не травмирует.

Кроме того существуют доверительные каналы, которые существуют покуда практикуется культурное пользование базой данных (файлами, без разницы). В доверительных каналах трансформация вообще не требуется.

Насчет лагов это уже второй раз когда о них говорят делая квадратные глаза и ничем не подтверждают их форму. Может какой-то бенчмарк?

Кстати, а как тогда по-вашему маркдауны-парседауны конвертят? Влет или ползком?

---------- Добавлено 07.08.2015 в 18:59 ----------

Например я могу в любую статью вписать и стили и скрипты и вписываю. Прямо в форме, текстареа, в админке. Почему я должен сам себя ограничивать убивая все эти полезные для впаривания средства? Потому что дескать есть тупенькая девочко, которая пользуясь той же админкой вставит туда тряхомудию из ворда или еще откуда-то и скомпрометирует свой комп? Тогда ее уволят. А инструктаж по кибер-гигиене и культуре они получают. Все просто.

Вы же понимаете что черная стрела на желтом треугольнике - для грамотных и культурных людей. КОторым если написали не влезай убьет - они не полезут. Для дикарей и долбоящеров придется майора ставить с пулеметом, чтоб не допускал. Поэтому дикари обходятся дорого, а грамотные люди - дешевле.

---------- Добавлено 07.08.2015 в 19:04 ----------

Кстати, такое мировоззрение что базу данных надо зачем-то защищать от хтмля возможно происходит потому что вы никогда не видели дампов и консоли, пользуясь теми же веб-апликухами типа PMA в крайнем случае.