насчет лишних выборок тоже понимаю.Проблема не в лишних выборках, а в структуре, которая на сегодняшний день считается классически малооптимизируемой.
если речь о порядке, то разные посты могут содержать разное количество тех же самых заголовков (именно заголовки части контента, подзаголовки, подпункты, 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>';unexpected variable "$body" in /var/www/u2142199/data/www/andreykrylov.ru/sendmail.php on line 26Читаем, переводим, понимаем, фиксим - профит.
В OpenCart такие проблемы тоже есть?Такие проблемы рано или поздно будут в любой готовой системе, как только вы сделаете какой-то немного нестандартный функционал. Проблема не в конкретной цмс, а в парадигме цмс как класса софта.
Чем можна заменить WordPress?Чем угодно, просто это может совершенно никак не повлиять на производительность. Крупные магазины пишутся под задачу, учитывая нюансы функционала и проектируя архитектуру под задачу.
CONCAT( ',', keywords, ',') LIKE '%,yandex,%'Кроме того что решение само по себе кривое, так еще и как минимум не будет работать если yandex первое слово в списке.
Океюшки, вот вам код.Океюшки, вот вам совет: Не пихайте непроверенные данные в файлы, которые лежат у вас на сервере. У вас код