Spizhen

Привет.
Раньше не доводилось такого делать, пришлось ядро расковырять...
По всей видимости без кастома компонента не получится. Когда через стандартное поле type=file грузишь, то данные о файле попадают в массив $_FILES где есть tmp_name - полный путь к временному файлу, а при использовании \Bitrix\Main\UI\FileInput в $_REQUEST где тоже есть tmp_name но с обрезанным значением


должно быть


В компоненте вызывается CIBlockElement::Add дальше -

CIBlockElement::Add --> CFile::CheckImageFile --> CFile::GetImageSize($arFile["tmp_name"], true, $flashEnabled)

вот в последней функции и происходит косяк, если tmp_name не полный (полный путь можно получить с помощью CIBlock::makeFileArray)

Пример кастома компонента (тестировал только для PREVIEW_PICTURE):
1. В файле component.php найди проверку

if($arResult["PROPERTY_LIST_FULL"][$propertyID]["PROPERTY_TYPE"] == "F")

замени
$arFile = $_FILES["PROPERTY_FILE_".$propertyID."_0"];
на
$arFile = ($_FILES["PROPERTY_FILE_".$propertyID."_0"] ? $_FILES["PROPERTY_FILE_".$propertyID."_0"] : CIBlock::makeFileArray($_REQUEST["PROPERTY_FILE_".$propertyID."_0"]));

2. В шаблоне template.php замени весь case "F":

for ($i = 0; $i<$inputNum; $i++)
{
	$name = 'PROPERTY_FILE_'.$propertyID.'_'.($arResult["ELEMENT_PROPERTIES"][$propertyID][$i]["VALUE_ID"] ? $arResult["ELEMENT_PROPERTIES"][$propertyID][$i]["VALUE_ID"] : $i);
	$value = intval($propertyID) > 0 ? $arResult["ELEMENT_PROPERTIES"][$propertyID][$i]["VALUE"] : $arResult["ELEMENT"][$propertyID];

	echo \Bitrix\Main\UI\FileInput::createInstance(array(
		"name" => $name,
		"description" => true,
		"upload" => true,
		"allowUpload" => "I",
		"medialib" => true,
		"fileDialog" => true,
		"cloud" => true,
		"delete" => true,
		"maxCount" => 1
	))->show(
		$value,
		$value ? true : false
	);
}

P.S. учти тот факт, что тестировалось только для PREVIEW_PICTURE для свойств, для мноржественных точно дописывать надо

Давайте обратимся к данной публикации, чтобы понять примерные тренды, потому что наиболее выгодный вариант – это все же фронтендер.

Вкратце, полноценный клиентский разработчик должен знать:
– html5/css3 + bootstrap
– один-два препроцессора (less/stylus)
– чистый js и пару-тройку клиентских библиотек или фреймворков (knockout/backbone/angular/react)
– немного node.js, чтобы уметь пользоваться пакетным менеджером (npm) и билд-менеджером (gulp/grunt)

Этот список покрывает большинство клиентских задач в средней студии или стартапе.

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

Другой вопрос – что со всем этим делать.

Я обычно предлагаю попытаться начать свой маленький проект. Какой-нибудь простенький личный сайт, игру на js (тот же flappy bird или 1048 – много ума здесь не нужно). Посложнее – свою тему или библиотечку. Это будет хорошим практическим опытом, который не стыдно описать в резюме.

Обязательным навыком является быстрое чтение документации (желательно на английском) и понимание того, что происходит в коде, который вы видите первый раз в жизни. Советую потренироваться на различных проектах с открытым исходным кодом.

Если говорить о личном опыте, то я неплохо подтянул js с помощью codewars – задачки начинаются от самых простых (преобразование строк, перебор массива), до очевидно тяжелых (собственные интерпретаторы и преобразование данных изображения).

А вот попытка спихнуть на верстальщика UI/UX – это уже экономия со стороны отдельных контор, которые по какой-то причине не хотят нанимать отдельного дизайнера/проектировщика в штат или по контракту. Тут, к сожалению, придется мириться и смотреть статьи по теме – тот же GoodUI.