imsha

Битрикс может вызвать отвращение к веб-разработке, его польза только в том чтобы потом ярче воспринимать Laravel/Symfony и инструменты на их основе. Всё потому что битриксоиды забили на стандарты и философию программирования напридумав кучу велосипедов из костылей и вылизав их до состояния production обложив рекламой и маркетингом. На западе про это знают, на них пиары 1С (OneAss) не особо действуют.

Кто видел код битрикса, тому АД не страшен.

Нет! Только не битрикс.
В ларавель, например, вам первым делом скажут слово "архитектура" - mvc. И вы будете прокачиваться в этом направлении, паттерны, архитектуры, юзкейсы, solid, все вот это вот. И это можно будет применить в любой области, хоть в php, хоть в java или c++, потому что это базовые вещи.
В битриксе - инфоблоки, арРезульт, компоненты, рабочая область и прочая шушера, которая кроме битрикса нигде никем не используется. И так и научитесь, что "программирование - это инфоблоки" и будете и дальше их клепать даже без битрикса.
Лучше выучите паттерны dao или repository вместо инфоблоков.
Крч не надо битрикса. И вордпресса и джумлы - это несерьёзно, правда.

Мало того, что не прокачает, так ещё и весь опыт будет бесполезен в другой стране.

Поставьте Debian и не парьтесь.

Судя по всему, вопрос касается облачной, а не коробочной версии Битрикс24.
Для воздействия на облако можно использовать лишь битриксовскую JS-библиотеку, но не собственные скритпы. Но вашу задачу с помощью неё не решить. Свои CSS-стили в облако тоже не встроить.

Это вам нужно либо переходить на коробку, либо закрывать сотрудникам доступ к контактам в стандартных настройках CRM и встраивать собственное мини-приложение которое будет отображать им лишь нужные данные, получая их по REST API.

Смотрите шире.

Сегодня React.js - доминирующая библиотека для рендеринга веб-страниц.
Для хорошего индексирования поисковиками - важно чтобы React.js рендерил веб-страницы еще и на бекенде и поисковики не получали пустые страницы.

Наиболее очевидный способ сделать это - запустить headless-браузер на node.js и отрендерить страницы предварительно на бекенде.

Т.е. связка реакт+нода - очевидна.

Но совсем не обязательно что весь отстальной бекенд сделан на Node.js. Обычно node.js - это так называемый middle layer между бекендом и фронтендом. Там где-то под копотом может быть хоть пхп хоть что-то еще.

ну, вариантов есть много, вот например:
Создаете из пыха файл restart.ngx когда нужно перегрузить сервер, из крона каждую минуту дергаете баш скрипт перезагрузки сервера если файл есть + стираете файл. Физически пых никак при этом не дергает систему.
Вопросы устойчивости системы и прочие "безопасности" смотрите по месту.

Нет, не "должен", но может. Лично я пришел к такой схеме:
- 200-ые статус коды отправляются ТОЛЬКО тогда, когда все прошло успешно. В таком случае не будет никаких success: true или response: {} - а нужные данные, прямо на первом уровне нестинга. Собственно если взять за правило, что 200-ые коды возвращаются когда все ок, то можно полностью избавлятся от этих плохих проверок на наличие ключа в респонсе.
- 400-ые и 500-ые будут попадать в отдельный колбек/реджектить промис, опять же избавляя от нужды проверять какие-то ключи. Для всех кодов ответов, кроме 400 и 422 - в ответе нету нихрена. Ни code, ни message, ни response. Вообще ничего. Вся инфа находится в самом http status коде. Для 400 и 422 прибавляется параметр code, который является номером ВНУТРЕННЕЙ ошибки (ну, например, есть какие-то предусловия для выполнения запроса - уникальность эмейл адреса при регистрации как пример) - по ней фронт может показывать отдельные ошибки либо выполнять какую-то логику.

Плюс ко всему этому у себя локально и на сервере для фронта включен дебаг, добавляющий некий параметр _debug к каждому ответу. В нем может хранится любая инфа - сообщение с ошибкой (даже если ее можно понять по http коду или внутреннему), стак трэйс 500-ой ошибки и тд.

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

P.S. Параметр code выглядит очень странно, есть коды ответа - используйте.

Визуальный редактор, настройка компонентов, некоторые другие вещи.
Лучше устанавливать mbstring.func_overload=0 только на нужные Вам папки.

1. Создаешь пользовательский тип записей для продукции + таксаномия, чтобы разбить всю продукцию на категории. С помощью плагина Custom Post Type UI либо ручками
2. Создаешь пользовательские типы данных для типа записей из п.1, чтобы для каждого товара прописать его характеристики например: цена, обьем, масса и т.д. С помощью плагина Advanced Custom Fields

Можно даже сделать "заказ в один клик" с плагином Contact Form 7