Александр Маджугин

В PHP можно не плодить функции на каждый чих просто из-за того, что у них разные аргументы. Например, так:

$input = SmartInput::parsePost([
  'id' => SmartInput::INPUT_INT,
  'sex' => ['type' => SmartInput::INPUT_ENUM, 'enum' => ['male', 'female', 'none'], 'default' => 'none'],
  'birthday' => SmartInput::INPUT_DATE_OPTIONAL,
  'phone' => ['type' => SmartInput::TYPE_PHONE, 'multiple' => true]
]);

Внутри функции - цикл и case.

if(\Bitrix\Main\UserTable::getList(['filter' => ['EMAIL' => $email]])->getSelectedRowsCount() > 0) {
    // E-mail существует
}

Ну вообще, если вы не планируете делать макет зависимым от установленного пользователем в настройках браузера кегля; меняете на различных брейкпойнтах лишь отдельные элементы, вроде заголовков; не планируете делать сайт доступным для разного рода телевизоров, то можете использовать px. Разницы тут никакой нет. А если вы еще и адепт pixel-perfect, и не делаете, например, размер подзаголовков зависимым от заголовков над ними, или отступы по краям кнопки зависимыми от кегля кнопки, то и em вам не нужен. Реальный кейс для осознанного использования rem \ em, который не является данью моде - когда заказчик хочет, чтобы было доступно везде, и при этом не требует pixel-perfect, оставляя разработчику свободу действий и выбора. Но это зачастую утопия.

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

У меня к вам встречный вопрос: Какой процессор и сколько оперативной памяти в этом компьютере?

Ставлю всегда
meta name="twitter:image" property="og:image"
и плевать.
Только путь к картинке там должен быть абсолют.

https://habr.com/post/120562/

Лучше тот инструмент, с которым лично ты (или нанятые тобой люди) лучше умеют работать.

Никаких принципиальных преимуществ нет у Node.JS.
Кроме того, что фронтендерам с Нодой лучше, привычнее, проще.

Подумайте, такие сильно нагруженные сайты как Facebook или Vkontakte - прекрасно живут на PHP.

Если вы представляете как сделать этот сайт с Node.JS, а не с PHP - делайте на Node.JS.
Если вы представляете как сделать этот сайт с PHP - делайте на PHP.
Лично я сделал бы с использованием Go. Но это я - а у вас опыт в другом.

Интересно, как ещё можно оптимизировать этот этап?

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

Это типичная задача упаковки (packing problem).

В «коробку» длиной 100 и шириной K надо впихнуть комплект колбас шириной 1 и разной длины.

Больше восьми лет работаю

css + html + js(уровень средний) + немного владею svg и canvas

Это очень мало, просто пипец какой маленький стэк для 8 лет. Бросайте wp, joomla хоть на несколько дней в месяц иначе вы останетесь там где были.

Мне кажется, что я останавливаюсь в развитии как разработчик.

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

многие используют PDF макеты

не встречал таких многих за 15 лет. PDF удобный формат, но не встречал. А в чем сложность с ними? Они отлично открываются в photoshop.

Я жестко отстаю, или просто хватает моих знаний/способностей для решения задач?

Вы научились делать простые вещи и дальше не пошли. Очень многие так поступают. Если денег хватает - то зачем? Тут как говориться "каждому свое". Я не могу так, мне надо разбираться во всем. Но среди моих знакомых есть очень много людей. кто тихо работает на студии с wp, получает 20k в месяц и счастлив по своему.

Может податься в мобильную разработку?

Смысл? Мне кажется надо просто понять, что пока Вы знаете ровно столько, сколько может выучить 9-ти классник за год - Вы стоите ровно столько сколько 9-ти классник. Хотите бабла? Знайте больше. Хотите еще больше? Знайте еще больше. Минимум 2 часа в день на обучение и все будет супер через пару лет.

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

Я уж молчу, как делить остатки между двумя сайтами???
Например, у вас в продаже20тн яблок. Сколько яблок можно купить на первом сайте? А на втором? Везде по 20 тн? А если сразу закажут и там и там? давать каждому сайту по 10 тн? А если на первый придет крупняк на 15 тн?)) Тут куча кода, который должны будут написать товарищи с широкораскатанными губами (это я про 1С-ников) - а ведь это люди с пожалуй наибольшим почасовым ценником в мире!!)))

Я же не отдам Некту яблоко, хоть он дерись!

Всё чуть сложнее, чем кажется.
1. Посли реги клиента мы определяем его клиентский идентификатор (CID; на основе браузера и подсети провайдера, к примеру)
2. Записывем его в базу на сервере и присылаем линк подтверждения регистрации на почту. Линк содержит криптованный клиентский ключ (серверным ключом, ключ для каждого клиента - генерируется свой).
3. После перехода по линку мы проверяем, что это действительно то устройство и наш пользователь, и присылаем ключ для дешифровки ключа и сохраняем его в браузер (Cookies или LocalStorage).
4. В момент загрузки закрытых данных (на сервере - они закрываются ключом авторизованного клиента), через JS мы берём ключ из хранилища браузера и дешифруем: пользователь видит чистые текстовые данные.

На любые "закрытые" данные нужно иметь всегда 2 ключа на их чтение: пользовательский и публичный.

Пользовательский - когда юзер залогинен.
Публичный - для всех, кто не залогинен. Он обычно НЕ используется, но если захотите какие-то данные открыть позже - нужно это предусмотреть заранее!

Как-то так...

Вёрстка никак не связана с CMS.
Вы путаете:
Существует вёрстка - "нарезка" PSD-макета в HTML/CSS.
А существует шаблон - вот он делается под конкретную CMS на основе вёрстки.

Если с верстальщиком была договорённость натяжки вёрстки на вашу CMS - пусть делает.
Если только вёрстка (макета) - то за шаблон придётся доплачивать, т.к. это отдельная дополнительная работа создания из HTML-вёрстки шаблона под заданную CMS.