Предлагаю посмотреть на такую архитектуру хранения файлов, администрирование и некоторые моменты разработки.
[spoiler]
Идея проста: файл отправляемый пользователем вместе с данными формы сохраняется не на сервере проекта, а в облачном хранилище одного из провайдеров.
посмотрим на html сформированный компонентом news.list:
<td valign="top"> <a href="/e-store/books/23/155/"><img border="0" src="http://c762048.r48.cf2.rackcdn.com/iblock/cf6/balmer.gif" width="65" height="107" alt="Этот негодяй Балмер, или Человек, который управляет "Майкрософтом" (пер. с англ. Клигман И.)" title="Этот негодяй Балмер, или Человек, который управляет "Майкрософтом" (пер. с англ. Клигман И.)" /></a> </td> |
Браузер посетителя пойдет за картинкой на сервер c762048.r48.cf2.rackcdn.com
Теперь об администрировании.
Сразу после заведения нового подключения (перед этим необходимо получить ключи доступа у конкретного провайдера) новые загружаемые файлы будут сохраняться в облачном хранилище. Для переноса уже существующих необходимо воспользоваться меню действий в списке подключений.
Всё выше сказанное относится только к файлам имеющим прописку в таблице b_file. Это связано с тем, что только для этих файлов система отвечает за формирование url. Весь прочий "мусор" так и останется в папке upload. Но тут есть хорошие новости: в следущих версиях будет реализован и перенос в хранилище "диких" файлов.
Для разработчиков
Необходимо отказаться от использования некоторых техник и воспользоваться API для работы с файлами.
Если необходимо получить ссылку на файл с протоколом и сервером, то раньше надо было писать примерно такой код (взято из компонента rss.out):
$arElement["DETAIL_PICTURE"] = "http://".$arResult["SERVER_NAME"].$arElement["arr_DETAIL_PICTURE"]["SRC"]; |
,то теперь код должен быть таким:
$arElement["DETAIL_PICTURE"] = CHTTP::URN2URI($arElement["arr_DETAIL_PICTURE"]["SRC"], $arResult["SERVER_NAME"]); |
Если нужно работать с содержимым файла, то код должен быть таким:
$arTmpFile = Cfile::MakeFileArray($FILE_ID); if(is_array($arTmpFile) && isset($arTmpFile[«tmp_name»])) $fc = file_get_contents($arTmpFile[«tmp_name»]); |
В случае облачного хранилища, копия файла будет скачана из облака во временный файл на сервере.
По окончании обработки хита, эти временные файлы будут удалены.
Функции класса CFile работают прозрачно за исключением функции ShowImage.
Первым аргументом эта функция может принимать и путь к файлу и ID.
Для облачных хранилищ желательно передавать ID.
Жду вопросов и пожеланий.
Фото:
Amazon S3
rackspace
и как следствие все OpenStack Swift
И да, оно на подходе.
Прописал насильно в вышеуказанном файле инклуд xml.php. Теперь запускается, но ничего не переносит (хотя bucket создать смог):
ЗЫ: А-а-а, я боюсь новую форму комментирования - елозит туда-сюда, лишние пустые строки непонятно как убираются, последний блока "кода" смог только с третьего раза вставить и то сначала вставил из буфера, а затем нажал кнопочку
1) в облаке
2) локально
вдруг с облаком что-то случается - останется локальная копия, да и легче делать переключение (если облако недоступно - выключаем его и вкл. доступ к файлам с сервера).
Как опция - думаю было бы очень здорово.
1) полная локальная копия всех файлов
2) копия в облаке
+
3) локальные бекапы
4) бекапы на удаленном сервере
5) бекапы где-то на s3
у нас просто интернет-магазин. Кластер...
И ваше утверждение, что с s3 ничего не может случиться - бред:1) проблемы с датацентром
2) проблемы с каналами интернет
3) и т.п.
Я понимаю, что это маловероятно, но, что плохого иметь доп. копию важной информации?
Есть ли разделение по сайтам или инфоблокам (одни локально, другие в облаке)?
Вкладка "Правила" в настройке подключения.
Это очень надо, как собственно и хранение всех файлов одного ИБ в отдельной подпапке в upload.
Добавленные события позволят легко реализовать "упорядочивание" хранения.
1) В обработчике сохранения элемента сохраняем ИД инфоблока в глобальной переменной.
2) Смотрим события в функции CFile::SaveFie.
3) За основу берем обработчик из облачного модуля.
4) Сохраняем файл по милым сердцу правилам.
А еще правильнее я так понимаю использовать GetFileArray
А в $arElement["arr_DETAIL_PICTURE"]["SRC"]; всё будет ок.
И я так подумал, что мне надо было какие-то махинации дополнительные делать. Для примера полез в news.list, но там картинки выводятся как обычно, и в component.php ничего с облаком не связано. Получается, мне ничего не надо делать тоже?
А зачем тогда
делать?
У меня все отвалилось вот почему: я картинки для списка дергал через CFile::GetList, одним запросом то бишь. И потом каждому файлу делал $arFile['SRC'] = '/' . $uploadDir .....
Максим, как тут быть?
Ведь если ранее это организовывалось на основании продажи доступа к некоторой группе пользователей то теперь такой возможности нет?
И даже не смотреть на это, можно ли сделать средствами системы номальные (более менее) ulr к файлам, то есть чтобы ссылка на файл на стороне сервера была не в виде а виде название_домена.сом/upload/iblock/6c15d64bd107374fc5709cc546e21a17/34b9dc337775104e76da44cbdd783403.pdf ?
То есть у нас всегда будет возможность подменять строку адреса через mod_rewrite, но просто не хочеться делать ненужные шаги).
У меня тоже сайт с продажей доступа к контенту, но у меня просто текстовая информация, у меня там нет никаких графических файлов, но если бы и были то я бы у себя их оставил. Ведь пока они у Вас, то они "подчиняются"Вашим правилам (я имею ввиду правилам Битрикса, которые Вы установили), а раз Вы их отдали Гуглу, то они будут уже работать по их правилам.
На данный момент вопрос был теоретическим) и ответ уже найден, но не методами системы.
И меня интересовало существуют ли для этого системные методы.
А можете подсказать какой метод найдем для решения этого вопроса? Мне тоже нужно сделать, чтобы ссылки на облачные файлы были на моем сайте внутренние, а не внешние.
Насколько я понимаю, для поискового продвижения действительно плохо, что ссылки на документы/картинки на сайте расположены на сайтах облачных хранилищ. Также по этим ссылкам, как я понимаю, прекрасно утекает поисковой рейтинг сайта.
В настройках облака есть "Настройка правил для отбора файлов в облачное хранилище" может там добавить 4е поле "Маска" чтобы можно было указать "*/upload/big-files/*"?
ЗЫ: в "big-files" складываются файлы 1 инфоблока, через кастомное свойство файл, то есть это файлы инфоблока.
У нас такая задача. У нас разрабатывается сервис сервис для загрузки и просмотра бухгалтерских документов. На сервисе есть данные "такому-то пользователю можно показывать такие-то документы".
Документы хранятся в виде PDF. Показываем документы через средство просмотра Google Docs Viewer, выглядит это примерно так:
Viewer показывает содержимое документа в отдельном фрейме, пример кода фрейма
Вопрос1: что собой представляет URL файла, который хранится в облачном хранилище? Можно ли это файл показать через Google Docs Viewer?
Вопрос2: чем обеспечиваются права доступа к файлу разным пользователям - средствами Битрикс или средствами облачного хранилища?
Заранее спасибо за ответ. Если не будет возможности ответить по существу - пожалуйста, дайте наводку на документацию, где поискать ответы
С уважением,
Сергей Ермолаев,
руководитель проекта Телебухгалтер
По второму - файлы в облако закачиваются с правами на чтение всем у кого подключен интернет. Для обеспечения дополнительной защиты вам потребуется смотреть механизмы защиты конкретного провайтера и реализовать их использование самостоятельно.
Пример ее использования можно найти тут /bitrix/modules/support/admin/ticket_show_file.php
Никто не сталкивался? Или на клодо все держат с кривыми ссылками?