блоки не будут зависеть от html, изменил компонент - изменился вывод всех зависимых элементов. с обычным html так не выйдет - в бд уже будет храниться строгий html, соответственно для изменений придется вносить изменения в КАЖДЫЙ пост (и речь не о стилях, а о разметке)Пример плс, а то что-то я не догоняю, как может поменяться "компонент" настолько, что поможет только его переписывание??? И чем поможет в этом случае ббкод?
Отдельные элементы одинаковые, соответственно можно использовать компоненты для того чтобы избежать дублирования кода.И какие элементы у вас тут одинаковые? И где вы увидели дублирование кода???
Другое дело что структура контента разная, получается что каждая контент часть поста уникальна по расположении отдельных элементов - обычной вьюшка не дает возможностей.То есть для какого-то блока у вас будет допустим выравнивание вправо, и вы будете создавать элемент с типом алигн_райт, прописывать его в новом ббкоде, а потом заменять его регулярками на элемент с классом алигн_райт? Не кажется проще сразу задать разметку с нужным стилем? Все современные wysiwyg редакторы поддерживают такое форматирование в один клик.
И тут либо bb коды, либо использовать совершенную другую логику.Вы как-то странно позиционируете ббкоды, как будто они сильно превосходят нативную стилизацию через хтмл... Как раз ббкоды - костыли, призванные сильно ограничить пользователей в кастомизации визуала контента, в статьях же вам скорее нужно использовать всю мощь современного хтмл/цсс.
Для ББ кода - это еще один код, вставленный в текст. Для html появится желание обойтись без дополнительного парсинга исходников и вставить кнопку как есть, со стилями и скриптом, или хотя бы с классами.Открою мааааленький секрет: Практически все тексты обрабатываются перед выводом. Некоторые для той же вставки рекламы, некоторые для обработки какого-то функционала, который никак кроме обработки метаинформации по другому не вставишь, некоторые именно для парсинга чего-то типа ббкодов(например если это непремодерированные данные от пользователей). Просто если данные введены из надежного источника и содержит готовый отформатированный хтмл, обработка становится в разы проще, например не нужны регулярки на каждый чих, можно просто найти нужный тег и заменить его на что-то другое стр_реплейсом... По этому никто не будет соблазняться вставкой кнопки в текст.
насчет лишних выборок тоже понимаю.Проблема не в лишних выборках, а в структуре, которая на сегодняшний день считается классически малооптимизируемой.
если речь о порядке, то разные посты могут содержать разное количество тех же самых заголовков (именно заголовки части контента, подзаголовки, подпункты, etc), которые могут находиться в произвольных местах. естественное дело, учитывать структуру необходимо.То есть "заголовки" не будут плавать и прочие блоки не будут плавать внутри контента выше-ниже, а просто будут иметь другой вид? Условно у вас есть название статьи, главная картинка, шорт дескрипшн, и неизменный текст статьи, элементы внутри которого просто стилизованы по разному? Не находите что проще задать им 8 тегов и забыть про какие-то там разбиения? Тем более что и семантически это положительно отразится на контенте, и краткость по сравнению с вашими шорттегами не ухудшится (например что вы там насокращаете в тегах
<h1>,<h2>,<h3>?.. Ну или сократите <span> до [sp]?..).видел также пост на хабре, где человек ровным счетом также хранил html код, перешел на подход похожий на второй, количество хранимой информации уменьшилось в 4 раза (имхо, разница отличная).Во первых накладные расходы на создание дополнительных записей и индексов сожрет сильно больше места, во вторых уверен что подход был похожий, но не такой, и в третьих - возможно что хтмл у товарища занимал СИЛЬНО больше места чем требовалось для обычного поста, то есть это были скорее всего совершенно другие данные. В вашем случае я привел экономию, если у вас тегов ОЧЕНЬ много, возможно вы выгадаете НЕМНОГО больше места чем описано у меня(вам все равно придется как-то обозначать все теги которые вы меняете, и это не сократит ВЕСЬ текст в 4 раза никак), но СИЛЬНО потеряете в производительности.
С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive. Ну если пересчитать удельно сколько стоит гигабайт.Это относится только к собственным серверам, и с натяжкой к арендным мощностям. На "готовых" хостингах например вы платите фикс прайс, не зависимо от использования/неиспользования бд. Ну и тут в целом речь не про "дешевле ли в файлах", а про "хранить какую-то часть данных в бд или генерировать ее программно", что совсем не одно и то же.
Так вопрос в этом и состоит, какой метод для этого подойдёт?Никакой, так как поток это по умолчанию набор байт, никак не связанный с пхп (например кусок открытого файла), какую переменную вы хотите извлечь оттуда - загадка. Собсно stream_get_contents() возвращает строку ровно по той же причине - в пайпе всегда содержится набор байт, а не объекты какого-либо языка.
//...
$params = [
':user_name'=> $this->user_name,
':user_email'=> $this->user_email,
':user_password'=> $this->user_password,
':user_profile'=> $this->user_profile,
':user_status'=> $this->user_status,
':user_created_on'=> $this->user_created_on,
':user_verification_code'=> $this->user_verification_code
];
var_dump($params); exit();
//...$mail->Subject = 'У вас письмо!' //здесь пропущена точка с запятой в конце строки
$body = '<h1>Заявка!</h1>';
Если нет - проблема в боте, если есть - проблема в ю. Смотришь лог ошибок, так как вряд ли что-то "не работает" просто так.