poniyur

Обычный градиент под углом на фоне.
Одна строчка кода.

background: linear-gradient(-45deg, red 50%, black 50%);

У меня переход цвета по середине. Сдвиньте куда нужно и если нужно.
Можно поставить на фон только одному блоку, второй оставить однотонным (а еще лучше прозрачным).
Можно задать градиент псевдоэлементу одного из блоков и спозиционировать куда нужно.

Вопрос с подвохом.
Потому что "данные, предоставленные пользователем" может означать что угодно. Поэтому формулировать надо так:

Надо использовать параметризованный запрос, если в запросе не используются переменные?

И тогда ответ будет простой и очевидный - нет, не надо.
Это очень простое правило: используются в запросе переменные? Используем подготовленный запрос и передаем через плейсхолдер. Не используются? Можно использовать query()

В качестве исключения, в запрос можно включать переменные, значения которых явно прописаны в коде, и не меняются.

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

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

но скоро прибежит зумингер и объяснит (по его разумению), что вы, мягко выражаясь, не человек.

Я думаю здесь подмена понятий. Автор пишет "кэширует ли БД запросы", а имеет в виду "может ли в принципе эта страшная и непонятная громадина которая называется базой данных в принципе хоть когда-нибудь рабтотать быстро?"
Все, разумеется, кидаются отвечать на первый вопрос.
А на самом деле надо отвечать на второй. Да, почти всегда БД работает гораздо быстрее чем ты можешь вообразить и ничего кэшировать не нужно. Если вдруг стало работать медленно... впрочем, об этом ниже.

Нужно ли делать кеширование запросов
Вот в такой формулировке, взятой с потолка, "а не закэшировать ли мне запросы к базе данных*" - Нет, не нужно.

и как?
Очень просто.
Три простых шага:
1. Понять, устраивает ли тебя производительность приложения. Если устраивает, то все оставить как есть.
2. Если не устраивает, освоить профайлинг. Если это слово не упоминается в вопросе про производительность или кэширование, то вопрос можно сразу удалять. потому что он заведомо взят с потолка и не имеет смысла. По сути, профайлинг - это замер скорости выполнения отдельных участков кода для поиска узких мест - т.е. таких участков кода, которые тормозят всю программу. Это можно делать и вручную, и с помощью различных готовых инструментов. Только по результатам профайлинга, который показал конкретную причину тормозов, то самое узкое место (его еще называют bottleneck, "бутылочное горлышко"), можно приступать к оптимизации. Не кэшированию!
3. Если профайлинг показал, что проблема в конкретном запросе к БД, приступаем к его оптимизации. Чаще всего достаточно добавить индекс или донастроить сервер.
4. Только если все другие способы не помогли - занимаемся кэшированием. Но перед этим сначала решаем Вторую Важнейшую Проблему Информационных Технологий - инвалидации кэша. Поскольку закэшировать - это ерунда, каждый дурак сможет. Самая главная проблема не в том, как данные положить в кэш, а как и когда их оттуда удалять.

При использовании SPA все внешние скрипты-инициализаторы контента должны быть ВНУТРИ SPA и никаких внешних загрузок!

За версионностью и корректностью их работы внутри SPA - также следите Вы (обновился внешний->сохранили к себе->проверили->обновили сборку SPA).

Если речь про контроль загрузки внешнего контента (скриптами-инициализаторами), то здесь придётся создать дополнительно ещё и верификатор доступности внешнего ресурса, загружаемого основным скриптом (из SPA). Это можно сделать через подписку на события отслеживания ajax-соединений (и других необходимых).
Например, так.

1. Используйте regex и проверяйте на невалидные цепочки слов и знаков препинания внутри текста перед постингом и нормализуйте токены-разделители.
2. Проверяйте сами слова на валидные символы (и их цепочки), на ограничение длины и на содержание в стоп-листе.
источник

<?php
$values = array(
    'text???',
    '???text',
    'text???text',
    'text ? ? ? ? ? text'
);

foreach ($values as $original_value) {
    $value = preg_replace('/([?!.:,;]|\s)\1+/', '$1 ', $original_value);
    echo $original_value . "\n" . $value . "\n\n";
}

Вот либа для русского языка: Typograph

Добавлю ещё, что если есть ограничение на количество символов в объявлении - то сразу лучше ограничить количество слов (2 буквы и более) не несущих смысл (союзы, предлоги и т.д.). Тогда текст объявлений будет намного качественнее для ЛЮДЕЙ (и для поисковиков, конечно)!

Что такое заспамленность в целом (понятия: водность, тошнота текста и др.): тут
Онлайн анализ текста: здесь

Т.е. это должно работать сразу, до принятия объявления системой (т.е., обычно, до его публикации).

https://www.php.net/manual/ru/function.idn-to-utf8.php
либо google -> php punycode

Все плохо

• Глобальные переменные — зло
  
• На лицо некий код, который и с сессией работает и с БД — явное нарушение общепринятных принципов, например SRP
  
• $dao как инициализирована? Явно не через конструктор
  
• Использование цифры, вот сиди гадай по ней — это плохо, используйте именованную константу. Например 3 — это некий статус для desktop, вот и назовите ее STATUS_DESKTOP, хотя далее...
  
• вы обращаетесь к одному методу, который шибко умный — работает с флагами, тем самым нарушая SRP и сам содержит if/else, сделайте просто 2 раздельных метода:
  

  getMobileOpinionList()
  getDefaultOpinionList()

  
  
• Предикат лучше вынести в отдельный метод isMobileOnly(), тк условия могут поменяться в нем, не будете же везде в if менять по всему проекту
  

Может, лучше без JS сделать средствами CSS?

@keyframes swing {
  0% {transform: rotate(-15deg)}
  50% {transform: rotate(15deg)}
  100% {transform: rotate(-15deg)}
}

ещё так можно
https://codepen.io/anon/pen/Jqrvzv?editors=1100

1. Изучить основы JS. тык
2. Изучить основы NodeJS. тык
3. Начать создавать свой проект.

JS это вообще клоака.
Очередность правильная HTML→CSS→JS
Правда препроцессоры вперед ногами пошли, их бы после базы, туда же бут и т.д.
Ну и в процессе грамотность верстальщика надо вытягивать. Это знание языка, правил, ГОСТ-ов оформления доков, сокращений и т.д.
Ну тут хотя как, многие (как и те, кто верстает только на дивах), думают, что фронтенд это типа бэкенда, только на JS. Т.е. если разобраться в JS и фрейморках, то в принципе можно проскочить попервой все, что выше, но в какой-то момент все равно вернешься.

З.Ы.: я как всегда удачно зашел, это одна из моих любимых тем. Чуть шире, чем тут, я ее раскрыл в статейке.

Сам я с удовольствием верстаю уже порядка 8–10 лет.

З.Ы.Ы.: Как показывает практика, многие, кто встает на путь истинный и учится верстать нормально, сдает позиции по принципу «ну его туда-сюда».