metallix

Вот современный способ проверки на соответствие медиавыражению:

if (window.matchMedia('(max-width: 700px)').matches) {
  for (const linkElement of document.querySelectorAll('.order-project__more-details-btn')) {
    linkElement.setAttribute('href', 'examples-foundation-640')
  }
}

А вот документация: https://developer.mozilla.org/ru/docs/Web/API/Wind...

1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
   
2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
   
3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
   
4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
   Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.
   

Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

• Актуален ли Yii2 Фреймворк в 2020?
  
• Какой подход программирования на PHP выбрать в 202...
  
• Переход к PHP-фреймворку. Какому?
  

Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.

Вам необходимо подключить к сайту google tag manager а после с его помощью настроить перехват действий, а именно клик на кнопку, что позволит сгенерировать вам виртуальную ссылку, которая будет автоматически попадать в гугл аналитику, и дальше на эту виртуальную ссылку вы настраиваете цели, воронки и т.д.

Redis - это хранилище структур данных в памяти с открытым исходным кодом (лицензия BSD), используемое в качестве базы данных

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

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

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Попробуйте nextjs. В нём много фишек и оптимизаций под Вашу задачу.

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

В целом, пользуйтесь тем, что комфортно.

Мне в свое время помогла проработка всех шаблонов проектирования из трех источников: "Head First Design Patterns"+refactoring.guru+designpatternsphp.readthedocs.io. Каждый шаблон разбирала и пыталась понять, почему здесь нужен паттерн, а не процедурный код, обернутый в один класс. Еще помогла книга по чистой архитектуре, но она зашла уже после паттернов. Просто важно полностью для себя понять, почему эти подходы до сих пор существуют и находить для себя два-три примера, потому что один-единственный пример для изучения может быть однобоким и даже неправильным.
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)

в основном так и есть.
бизнесу насрать на наши модели и архитектуру, ему надо деньги делать и ещё вчера.

если вылизывать архитектуру со старта - никогда не взлетишь. а когда и если взлетишь, поляна будет уже засеяна другими, которые срать–плевали на красоту кода.

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

sarcasm_on
Да, в статье 99 Трудового кодекса так и написано

2)... бэк енд должен самостоятельно сделать админку при разработке бэк енд

8)... бэк енд разработчик должен сам понять и не утруждая заказчика сделать админку

sarcasm_off

Автор, проснись! Что за глупые вопросы? Какой «должен»? Как договоришься, так и будет. Конечно, заказчик хочет навалить на исполнителя побольше за те же деньги.

https://www.json-generator.com/
пользуюсь им уже лет 5, если не дольше.

с такой постановкой вопроса - лучше вообще не писать.
и вопрос, если уж стоит, должен быть: не на чем, а как.