Артем

В первую очередь смотрите физический файл. Узнать его местоположение можно по URL адресу.
Если такого файла не существует, значит страница создается динамически. Тогда нужно посмотреть в настройках сайта Правила обработки адресов и узнать, какой физический файл отвечает за показ данной страницы.

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

Универсального ответа нет. Всегда нужно смотреть и подробно изучать код конкретного сайта.

Атомарный CSS в качестве основной методологии - это бред даже для лендосов, а уж в крупных проектах это просто апокалипсис.
Но он имеет право на существование в малых дозах, как локальные уточнения для обработки всяких исключений и частностей.
Сколько вы кладете в еду соли и перца относительно объема остальных продуктов? Вот столько в коде страницы должно быть атомарных стилей.

Удобно? Хм…

Ну раз удобно, попробуйте использовать выданный ими код в реальном проекте — сразу всё поймёте :))

Почесать собственную спину с помощью мизинца на ноге — и то удобнее будет.

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

Нам нужно, чтобы контентщик мог самостоятельно создать новую страницу. Значит, будет 1 инфоблок, а страница -- это элемент инфоблока. Т.е. при создании страница автоматом получит динамический адрес.
Вся информация в блоки на странице будет выводиться через свойства инфоблока. Их нужно будет красиво сгруппировать. Каждая группа свойств -- отдельный блок. У каждой такой группы будет 2 обязательных свойства: активность блока и сортировка блока. Галочка активности будет отвечать за показ блока на странице. А сортировка будет указывать положение блока относительно остальных блоков (т.е. устанавливать порядок блоков). Остальные свойства в группе -- индивидуальны для каждого блока.
Вам останется только разместить на физической странице комплексный компонент Новостей (чтобы включить ЧПУ) и переписать шаблон детальной страницы (реализовать группировку свойств, вывод и сортировку блоков).
В результате получится небольшой конструктор страниц, с которым справится даже ребенок.

Компонент catalog.section хранит данные по ценам ТП в массиве $arResult['ITEMS'][N]['OFFERS'][M]['PRICES'] , где N - порядковый номер элемента, M - порядковый номер ТП.

Таким образом, чтобы получить цены ТП можно использовать цикл:

foreach ($arResult['ITEMS'] as $arItem)
{
   foreach ($arItem['OFFERS'] as $arOffer)
   {
      $arOfferPrices = $arOffer['PRICES'];
      // здесь работаете с ценами конкретного ТП
   }
}

антивирус для сайтов https://revisium.com/ai/

https://github.com/RobinHerbots/Inputmask

file_get_contents получает исходный код страницы, как и задумано.
Вы делаете echo, и выводите этот исходный код в браузер.
Браузер видит html-код и исполняет его, как и задумано.

Что именно вам не нравится, и что вы хотите изменить?

set $base /var/www/lfp/data/www/domain.com;
root $base/var/www/lfp/data/www/domain.com;

если правильно понял, то будет

root /var/www/lfp/data/www/domain.com/var/www/lfp/data/www/domain.com;

не думаю что у вас такой путь есть.
на деле как понял первое поле (path) до пути проекта, а второй (document root) где лежит точка доступа и нужно писать относительно первого пути

<img :src="item.photo" />

Require не нужен. Работайте с адресом картинки как с обычной строкой.

Зачем задавать фиксированную ширину кнопки, контент внутри нее может поменяться. Лучше задать внутренние отступы

Есть несколько вариантов решения это проблемы.

1) Некоторые могут пропагандировать сервисный слой (design-pattern.ru/patterns/service-layer.html), как следствие: "App/Services/ServiceName" - набор классов, отвечающих за какое-то абстрактное действие. Например: "UserAvatarUploaderService", который отвечает за загрузку аватарки пользователя.

2) В качестве альтернативы и способ, который предпочитаю я - это создание директории "src" с набором независимых компонентов, включая собственный composer.json. Тот же сервис загрузки аватарки будет выглядеть следующим образом:

- src/
    - AvatarUploader/
        - README.md
        - composer.json
        - tests/ ...
        - src/
            - AvatarInterface.php
            - FileSystemInterface.php
            - FileSystemUploader.php
            - UploaderInterface.php

Для подключения этой библиотеки достаточно будет прописать в корневом:

{
    "repositories": [
        {
            "type": "path",
            "url": "./src/AvatarUploader"
        }
    ],
    "require": {
        "app/avatar-uploader": "*"
    }
}

А выглядеть внутренний (т.е. внутри "src/AvatarUploader") composer будет так:

{
    "name": "app/avatar-uploader",
    "autoload": {
        "psr-4": {
            "AvatarUploader\\": "src/"
        }
    }
}

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

Суперлузер? Серьезно?
Ок, размер рабочей области зависит от предпочтений и фолбеков.
Например, мое разрешение монитора сейчас как раз 1920, то есть картинка шириной 1920 будет как раз 100% ширины экрана... не учитывая полосу прокрутки и рамки окна. То есть нужны поля. Допустим по 15 пикселей(у меня не ретина, так что мой монитор имеет 72 точки на дюйм). Итого 1920 превращается в 1890, если надо контент делать на всю ширину (section-fluid в бутстраповых классах).
1920 это сейчас считаем как дефолтный монитор(смотрим по статистике), а на момент создания бутстрапа они зафиксировали 1170 как минимально допстимое разрешение десктопа, потому контент вписывают на такой размер(учитывая поля по 15 пикселей это разрещение 1200*800) как наиболее используемым разрешением.
Дальше 1280 это популярная ширина в разных разрешениях, как брекпойнт. Но уже без полей.
960 это из за одноименного фреймворка, где это число используется для фолбека на 1024*968 разрешение плюс поля, округление до нормального делительного числа.
Число 960(как и остальные перечисленные Вами) выбрано потому что удобно делить на колонки с полями. На 2/4/6/8/10/12/16/24

Берите ширину в зависимости о того, как будете верстать. А, ну и погодите, если Вы получаете готовый дизайн, то Вам не сильно получится "брать" какую то ширину контента, а придется работать с тем, что дали.
Опять же, будете ли пользовать фреймворки - тоже ограничит/упростит выбор ширины.
Забивать не надо. Если забили на ширину контента, то либо просто накалякали какую-то свою ширину, но все равно единую, либо вообще разброс по секциям/блокам. Вы вполне сможете потом свести всё до единой ширины, которую сами выбрали, если заказчик согласен и не требуется пиксель перфект по контентной области(обычно нет, и вполне обьясняется заказчику требованиями "соответствия для старых мониторов" или что то такое, после чего они соглашаются)

Зависит в основном от этого: