Талян

$url[1] = preg_replace('/\?\S+/', '', $url[1]);

А в разделе MY SKILLS надо будет написать "Умею задавать вопросы на Тостере, сам ничего не делаю".

Решение есть тут например.
Кто как адаптивно верстает 50% бэкграунды (слева одна картинка, справа другая)?
Там более сложный пример, но думаю, при правильном рассмотрении примера, разберетесь.

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

PS: Когда что-то пытаетесь делать, прикладывайте СВОЙ код, который не получился.
Вам будут указывать на ошибки и давать советы.
А делать верстку за вас никто не будет, тем более на сервисе Вопросов и Ответов.

PPS: На большом мониторе в вашем примере будет большая жопа, так как картинка растянется по ширине и на всю высоту блока будет лицо, а не полная фигура человека %)))
Если вы реально запланировали сделать картинку прижатой к левому краю.

Удачного плавания на просторах сайтостроения :)

PPPS: Короче, пришлось все-таки для ответа нарисовать пример.
https://jsfiddle.net/oz8mgcwp/
Но большего не сделаю)))

тащемта их завезли ещё в пхп5.
в 7.1 прост расширили их действие на константы.

1) Препроцессоры позволяют вводить переменные и миксины. Но ведь в CSS можно просто создать свойство

Ну, одно дело добавлять к селектору в css, другое дело захламлять html, а там уже сложнее будет менять класс (т.к. html может генерироваться как угодно).

2) Валидность CSS.

Ай, да на это пофиг, есть и другие средства для проверки.

3) Компилятор из препроцессорного языка в CSS.

Ну там легкий скриптик выполняется в сборщике автоматом (на webpack, gulp, parcel и.т.д.). Особо ничего не нагружает, на ssd при сохранении файла scss меньше чем за секунду компилируется css.

4) Удобочитаемость кода, и простой поиск,

А тут как раз наоборот. Искать по scss гораздо сложнее, т.к. нельзя врубить поиск по целому селектору. Но если стоит Sourcemap (грубо говоря, который учит инструменты разработчика хрома понимать scss), то уже можно спокойно смотреть в хроме номер строки, название классов и.т.д.

5) Возможность инклюда (include) в препроцессорах.

Оптимизация. Пока не пришел http 2, все ресурсы желательно склеивать, скрипты, стили и даже картинки в спрайты. Один файл грузится быстрее чем несколько, т.к. достаточно одного http запроса. С приходом http2 будет пофиг.

6) Вложенность свойств.

Ну вот смотри, есть у меня такая менюшка

<nav class="menu">
   <ul class="menu__list">
      <li class="menu__item menu__item_active">
         <a href="#" class="menu__link">Menu 1</a>
      </li>
      <li class="menu__item">
         <a href="#" class="menu__link">Menu 2</a>
      </li>
   </ul>
</div>

В css мой код на БЭМ будет выглядеть вот так

.menu {

}
   .menu__list { }
   .menu__item { }
      .menu__item_active { }
      .menu__item:hover { }
   .menu__link { }

а на scss вот так

.menu {
   &__list { }
   &__item { 
      &:hover { }
      &_active { }
   }
   &__link { }
}

проще и лаконичнее. Но этой слишком простйо пример. Там еще можно добавлять медиазапросы, дополнительные модификаторы.

7) На хабре видел в комментариях обсуждение, мол можно даже задавать в препроцессорах - какие браузеры поддерживать. Ахтунг! А зачем писать такие стили, которые не будут работать в старых браузерах?

Это больше для вендорных префиксов и всяких полифилов. Это по моему в PostCSS юзается через doiuse, точно не знаю, в scss с таким не сталкивался. Обычно пофиг на старые ie.

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

В маленьких проектах чаще да, если нет готового сборщика, то удобнее сразу писать прототип на css. Но сейчас любой фрейморк в пару команд позволяет добавить поддержку scss.

Это удобная штука, не нужно ее бояться, не нужно бояться webpack, фреймворки, но и не нужно фанатеть, это просто инструменты.

достаточно только первого пункта.
когда захотите поиграться шрифтами, цветом, размерами и придется бегать по всему файлу или файлам для их изменения, вместо правки переменных в одном месте.

2) ни о чем.
3) при нынешних объемах дисков и размере этих самых компиляторов говорить об этом не имеет смысла.
5) инклюды в препроцессоре дают возможность разбить весь css на отдельные небольшие и логичные файлы, с которыми проще работать, и на выходе сольют их в один файл, а не n разных в случае link rel. это хорошо в плане client-side optimization, хотя для хомяков и не критично.

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

Ищите "dependency walker".

function pew(selector) {
  if($(selector).val().length != 0) {
    $(selector).removeAttr('style');
  } else {
    $(selector).css(styles = {
      borderColor : "#dc4747",
      background: "#feecec"
    });
  }
}

['#sitename', '#desc', '#metadesc'] // и все остальные сюда
  .forEach(selector=>pew(selector))

А может быть вам подойдет что-то такое:

$('#myForm :input').on('change', function(){
  $this = $(this)
  if($this.val().length != 0) {
    $this.removeAttr('style');
  } else {
    $this.css(styles = {
      borderColor : "#dc4747",
      background: "#feecec"
    });
  }
})

isset() проверяет существование.
У вас в коде всегда передается name = ''
Можно сделать так:
if (isset($_POST['name']) && $_POST['name'] != '')
Рекомендую пользоваться функцией var_dump для отладки и проверки состояний переменных

буттон он клик функшн - иф первый радио из чекед - попап 1...
логика на уровне проверить-показать, что сложного?

Дубликаты ищем группируя по значению и фильтруя те, которых меньше двух
Пример

SELECT
    valueField1,
    valueField2,
    count(*)
FROM
    myTable
GROUP BY
    valueField1,
    valueField2
HAVING
    count(*)>1

Не забудьте указать все значимые поля.

Удалять по какому принципу? Все, кроме первого попавшегося?