30 ноября 2012 в 15:09
Добрый день уважаемое сообщество. Возникла вот такая задача: необходимо создать внтурикорпоративный фотобанк, чтобы каждый пользователь мог загружать и управлять своими (и только своими) фотографиями. Каждая фотография может принадлежать одной или нескольким категориям. Всего планируется порядка 10-15 тыс. фотографий. В дальнейшем, возможно понадобится создать комментарии для фотографий. Корзина не нужна.
Вопрос: подойдет ли друпал для такой задачи? Если да, то какую ветку лучше использовать, и на какие расширения стоит обратить внимание. Заранее благодарю за ответы.
Комментарии
сделать можно, но это будет в рамках друпала, его админки, специфики работы и т.п.
то есть, легкости и удобства работы как на istockphoto вы не добъетесь с друпалом.
Делал такое, только в разы сложнее(правда я программист)
да как нефиг, только кодить придется
угу, дофига кодить... вопрос, нафига тогда друпал здесь нужен? проще (и правильнее) написать свою систему.
То что вы описали, можно сделать стандартными средствами + views.
Думаю сейчас имеет смысл только 7-ую использовать.
На мой взгляд, если не надо, чтобы права доступа для скачивания картинок были различные для различных пользователей, то подойдет, если же перед тем как отдать каждую картинку надо права проверять, то только если относительно немного запросов на скачивание картинок, ибо на каждую скачку весь друпал будет загружаться (если конечно это его штатными средствами реализовывать - drupal private files system).
Во-первых, есть x-sendfile и подобное.
Во-вторых, времена, когда экономили CPU проходят. Современные процессоры уже настолько мощные, что можно себе позволить отдавать файлы через php, а сервера, как правило, упираются в диски, RAM, и сеть. У меня на сервере, например, i7-920 большую часть времени простаивает, только когда iowait растет, начинаются тормоза.
Я полагаю, фотобанк не будет работать на шаред хостинге
Вопрос из серии
"Я хочу полететь на Луну, подойдет ли мне строительство космодрома возле Киева."
Я потому и спрашиваю, при условии, что с этой системой я совсем не знаком: стоит ли связываться имея такую задачу, с друпалом, есть ли какие-то похожие решения.
А ответы типа "Я хочу полететь на Луну..." ничего в себе не несут кроме собственного апломба, уж извините.
Manas, я просто образно выразился.
Лично мне не известны никакие объективные причины против использования Drupal для вашей задачи. Сомневаюсь что они есть.
На вопрос использовать ли Друпал должен отвечать либо тот кто делает либо тот кто заказывает. Попробуйте сделать или заказать сначала маленький сайт, потом его увеличить. узнаете насколько вам подойдет Друпал.
Вообще, именно по сабжу вижу обычную связку D6+Node Gallery(+,возможно, Node Access) + пара вспомогательных модулей, хз есть ли аналоги Node Gallery(в этом модуле именно тот функционал, что Вы описали) в 7 ядре, но должны быть, т.е. без единой строчки кода.
А если рассматривать конкретно istockphoto, я собирал подобное, можно собрать на базе комерца или убера(без разницы), но лучше делать свой велосипед магазина(т.е. свою систему, как уже говорил kervi), ибо в случае велосипеда кода будет раза в 3 меньше(т.к. этих 2х товарищей надо будет допиливать огромным числом костылей и в некоторых местах хакать(иначе привет таймауты по всему сайту)), в этом случае друпал как минимум не хуже любого другого фреймворка, однако не придется изобретать все остальное, например систему управления пользователями, и прочее, ибо за эту часть друпал будет отвечать как CMS, а за магазин как фреймворк, НО, если не знать drupal api на уровне джедая, то быстрее и правильнее будет собрать сие на том, что знаете(именно на уровне джедая), если же не знаете ничего, то drupal, по моему мнению, прекрасно подходит(это если Вы знаете(на профессиональном уровне), как минимум, PHP и MySQL), однако приготовьтесь к тому, что у Вас уйдет минимум пол года(на зенде, к примеру, мне кажется, что времени уйдет больше, ибо одной тыщей строчек кода там не отделаешься) на то, чтобы, например, сделать аналог istockphoto. Но не исключаю, что можно найти уже готовую CMS под эти конкретные нужды.
Из коробки - нет, с модулями - терпимо, с оригинальными модулями - почти все что надо можно сделать.
Всем спасибо за ответы. Думаю, что попробую. Тем более уже давно хотел ознакомиться с данной системой.
Система отдачи друпалом приватных файлов не использует такие вещи, а я делал ремарку
Если использовать механизм, встроенный в друпал, то будет RAM расходоваться во время загрузки файла.
у x-sendfile есть небольшой минус в том, что наше приложение не знает скачал пользователь файл или нет. Это имеет значение если нужно отдать пользователю файл один и только один раз, и если связь с пользователем прервалась во время отдачи, а у нас уже записалось в базу, что оплаченный файл был отдан, то больше он его не получит.
Ядро много чего не умеет из коробки. В моем понимании, такой крупный проект, как фотобанк, может использовать любые кастомные модули, а если надо, и похакать ядро, или написать свой обработчик файловой системы, который не делает полный бутстрап.
Готовые решения есть http://drupal.org/project/xsend правда я сам не пробовал. Не было такой задачи..
Разумеется. Но есть такая штука, как буферизация в веб-сервере (например в nginx). Для маленьких и средних файлов самое то. А большие все равно через x-sendfile нужно. Суть в том что процесс php не занимается обслуживанием доставки до (медленного) клиента. Он может жрать память, но молотить при этом гигантское кол-во файлов. Только размер буфера побольше нужен (вернее, достаточно большой).
При такой конфигурации нагрузка по RAM смещается в сторону nginx. Т.е. это все равно круто, если файлы маленькие, а бутстрап тяжелый т.е. сэкономленная на бутстрапах память должна перекрывать расход на буферы nginx.
У меня есть большое подозрение, что из-за возможной буферизации эту информацию в любом случае нельзя получить со 100% надежностью.
друпал тут не причем, из альтернативных способов знаю, только что эту проблему можно решить через nginx, правда сам с этим пока не замарачивался.
единственный вариант лечения этого минуса - написать какой-нибудь клиент сайд даунлоадер, ибо в обычном случае, максимум, что можно проверить - был ли файл отдан, но вот был ли он получен целым и записан на диск... как говорится, это уже проблемы того, кто скачивал, ну либо я Вас не так понял.
Передо мной тоже не стояла такая задача, про такой модуль не знал, надо будет из интереса взглянуть на него, спасибо. Правда он только под 6-ку.
Есть и под семерку аналогичный там же - поищите.
Вообще сейчас представляю себе решение сайта стоковых фотографий с помощью друпал таким образом:
1) Высокого разрешения фотографии, доступ к которым нужно ограничивать, закачиваются в приватную файловую директорию
2) Создаются превьюшки с вотермарками и уменьшенным разрешением и кладутся в общедоступную файловую директорию
3) При открытии доступа к какому-то файлу для какого-то юзера делаем запись себе в таблицу uid | fid, что файл куплен.
4) При запросе на скачку стокового фото отдаем его после проверки записи в своей таблице, через x-sendfile
5) Гарантировать однократную скачку мы фактически не можем, иначе есть шанс лишить пользователя купленного фото при разрыве связи, но можем удалять запись из таблицы спустя некоторое небольшое время
Спасибо. Как положить в приватную папку, понятно. А как сделать, чтобы превьюшки были в общедоступной паке при этом?
на самом деле достаточно посмотреть реализацию uc_file(в ядре уберкарта, вроде) или dc_fileчтототам, логика в в данном случае у них будет одинаковая. Т.е. сей велосипед уже давно изобретен, в плане архитектуры.