Илья

Вызов печати выводите через window.print, а стили все остальное реализуется через CSS:
@media print { /* Стиль для печати */ }

Если на SQL, то запрос будет выглядеть так:
SELECT * FROM post ORDER RAND() LIMIT 5;

В письмо зашиваете ссылку на сервис/страницу/раздел на сайте, который будет менять статус нужного заказа. В параметрах передаете ид заказа и токен (чтоб без авторизации). Токен можете генерить на основании заказа (например "соль + ид заказа + email покупателя"), чтобы быстро его можно было сравнить и не париться с хранением.

QR код формировать можно на лету, если он нужен в счете, то при формировании счета. Далее уже при отправке письма со счетом, формируете PDF документ с имеющимся QR.

По поводу библиотек: https://habr.com/ru/post/92094/ , https://snipp.ru/php/qr-code
Ни одну не юзал, поэтому не могу рекомендовать, но думаю проблем не должно быть

Так себе решение размещать классы в php_interface. Создайте отдельный модуль, подключайте его в init.php (если нужен модуль всегда) и все. Все классы подгрузятся автоматически в соответствии с именем класса.

Ну а про неправильное имя вам уже в комментах написали.

Создаете архив с json (например) файлом внутри с данными, отправляете файл клиенту.
Пример работы с zip: https://www.php.net/manual/ru/zip.examples.php
-
Либо можно сжать просто строку: https://www.php.net/manual/ru/function.gzencode.php

В main.js разве Vue.use(VueRouter); не нужен?)

P.S. по поводу структуры: https://habr.com/ru/post/483064/
P.S.S. по поводу туториала - у vue один из самых норм туториалов и на главной странице его подключение есть: https://router.vuejs.org/installation.html

В порядке простоты решения:
1. При выводе использовать стандартный зум
2. Добавить еще одно свойство с зумом
3. Расширить свойство "Пользовательских яндекс карт" и добавить внутрь самого свойства зум

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

Правильно отделять представление от логики (см. MVC).
Поэтому у вас должны быть 1 представление - с формой, 1 контроллер - для обработки данных формы.
Ну а вообще ваш пример мало что общего имеет с ООП (то что вы создали объект, не делает код ООП).

P.S. пробуйте лучше на основе фреймворков, а не голой PHP не тратьте время зря. Используйте например Slim: www.slimframework.com , он возьмет на себя всю "грязную" работу по обработке запросов и вьюх, а вы сможете сосредоточиться на ООП.

P.S.S. не про ООП, но все же - именуйте переменные так, чтобы было понятно что происходит и что каждая из них содержит

Бизнес-процессы - это обычные списки. Списки - это обычные инфоблоки. Т.е. если вам нужен сам документ - то ищете по элементам инфоблоков. Если сам процесс (задания бизнес-процессов), то ищите в таблицах b_bp_*, конкретно в b_bp_task

CSV простой текстовый формат, он такое не умеет.
Смотрите в строну XLSX и PhpOffice: https://phpspreadsheet.readthedocs.io/en/latest/

P.S. вместо php://output, лучше использовать php://temp, тогда с буфером возиться не придется

Что значит глубокий объект? Древовидная иерархия имеется ввиду или что?
Если да, то в сторону https://vue-treeselect.js.org посмотрите

При любом раскладе у вас каждый объект должен идентификатор иметь, и тогда select будет хранить не весь объект, а только его идентификатор.

В настройках модуля торговый каталог: https://i.imgur.com/WzPgTi6.png

А кто делать то будет? Мне кажется надо отталкиваться от того какой стек технологий знает тот кто разрабатывает. Если есть знания, то можно и на Yii2 чистом, либо на YupeCMS сделать. Либо если знаете Битрикс, то можно на нем. Функционал +/- стандартный, есть везде.
Поэтому правильней вопрос поставить "какую CMS использовать чтобы потом не было больно"

А проблема в чем? То что нет подходящего готового кода?

Автомагически темы не подключаются, если брать к примеру стандартный компонент "main.interface.form", то в файле component_epilog.php темы подключаются вручную:

<?php
// ...

if($arResult["OPTIONS"]["theme"] <> '')
{
	$APPLICATION->SetAdditionalCSS($templateFolder.'/themes/'.$arResult["OPTIONS"]["theme"].'/style.css');
}

Мне кажется структура проекта должна быть удобным для работы с ним, и основное условие это модульность и разделение обязанностей. И в плане производительности подключить один класс со всеми константами, наверное будет не намного производительнее чем пару классов с константами (и немного странно что константа используется без самого класса, ну то есть если используется константа для работы с БД, то логично было бы расположить ее в маппере который с БД и работает). Как вариант можно вынести общие константы, которые используют несколько модулей. А остальные оставить в используемых классах.