Drupal → WYSIWYG image upload
Возможности:
Страница модуля
- Простой и быстрый интерфейс для загрузки картинок
- Поддержка редакторов TinyMCE, FCKeditr, YUI (Любой редактор, который поддерживает WYSIWYG модуль)
- Поддержка ImageCache. Возможность выбрать пресеты.
- Возможность установка произвольных размеров используя drag&drop
- Основан на WYSIWYG моделе и его API
- Возможность установить атрибуты картинки Title, Обтекание текстом, и Styles (Border, Spacing) и Пресеты ImageCache
- Полностью основан на Drupal FAPI
- Диалог основан на jquery ui dialog
Страница модуля
Блог им. voofer → кроссдоменный UPLOAD файлов с прогресс баром, без перезагрузки страницы, и без использования флеш
Драсте всем.
Спасибо что решили почитать этот пост.
Задача состояла в следующем, в связи с тем что широко известный загрузчик файлов FancyUploader, не всегда, но довольно часто глючит, особенно если использовать прокси, нужно было разработать систему, по которой при загрузке файла показывался прогресс бар… Всё бы ничего, таких систем много, но все либо используют другие флеш загрузчики или иные Апи, что в данном случии являеться негативным результатом разработки.
После некоторого времени поиска была найдена система основанная на модуле apc habrahabr.ru/blogs/webdev/17620. Всё бы хорошо, но вешать дополнительный модуль кеша на сервер где кеш технологии уже используеться было безсмысленно. Тогда мне в руки попалась информация о NGINX upload progress module (http://wiki.nginx.org/NginxHttpUploadProgressModule) и это действительно работает… Тем более что на наших серверах установлен именно nginx в качестве fronе-end сервера.
Но самое интересное оказалось впереди.
Обычно загрузка файлов осуществяеться в то место где и лежит сам сайт (на тот же домен), но у нашей компании это не так. Все картинки и видео лежат на одельном сервере, и соответсвенно хорошо если upload был бы сразу на него, что бы не загружать канал сайта.
После конфигурирования nginx с upload progress module и использование примера с wiki.nginx.org/NginxHttpUploadProgressModule прогресс бар загрузки файла заработал.
Для пересылки самого файла на нужный сервер было изменено не много, и сам же сконфигурированных nginx естественно должен находиться на h_t_t_p://STORAGE-SERVER.com.
<
Спасибо что решили почитать этот пост.
Задача состояла в следующем, в связи с тем что широко известный загрузчик файлов FancyUploader, не всегда, но довольно часто глючит, особенно если использовать прокси, нужно было разработать систему, по которой при загрузке файла показывался прогресс бар… Всё бы ничего, таких систем много, но все либо используют другие флеш загрузчики или иные Апи, что в данном случии являеться негативным результатом разработки.
После некоторого времени поиска была найдена система основанная на модуле apc habrahabr.ru/blogs/webdev/17620. Всё бы хорошо, но вешать дополнительный модуль кеша на сервер где кеш технологии уже используеться было безсмысленно. Тогда мне в руки попалась информация о NGINX upload progress module (http://wiki.nginx.org/NginxHttpUploadProgressModule) и это действительно работает… Тем более что на наших серверах установлен именно nginx в качестве fronе-end сервера.
Но самое интересное оказалось впереди.
Обычно загрузка файлов осуществяеться в то место где и лежит сам сайт (на тот же домен), но у нашей компании это не так. Все картинки и видео лежат на одельном сервере, и соответсвенно хорошо если upload был бы сразу на него, что бы не загружать канал сайта.
После конфигурирования nginx с upload progress module и использование примера с wiki.nginx.org/NginxHttpUploadProgressModule прогресс бар загрузки файла заработал.
Для пересылки самого файла на нужный сервер было изменено не много, и сам же сконфигурированных nginx естественно должен находиться на h_t_t_p://STORAGE-SERVER.com.
<
Блог им. sheremetat → Загрузка фотографий на сайт c помощью электронной почты
Это мой первый пост на Хабре, по этому не судите строго.
Реализовать возможность загрузки фотографий в профайл или в фотоленту события посредством электронной почты, поместить их в заданную папку и сделать соответственную запись в БД.
Пользователь отправляет письмо с фотографиями на адрес типа userXXX_eventYYY@mysite.com, где eventYYY — ID события; userXXX — ID пользователя. Такого e-mail адреса НЕ СУЩЕСТВУЕТ. По этому все письма отправленные на несуществующие адреса перенаправляем на image_upload@mysite.com. Потом, при считывании почты с этого адреса, парсим заголовки и узнаем на какой адрес изначально было отправлено письмо. Распарсив полученный адрес, узнаем КУДА складывать файлы и кто их залил.
Задача.
Реализовать возможность загрузки фотографий в профайл или в фотоленту события посредством электронной почты, поместить их в заданную папку и сделать соответственную запись в БД.
Алгоритм
Пользователь отправляет письмо с фотографиями на адрес типа userXXX_eventYYY@mysite.com, где eventYYY — ID события; userXXX — ID пользователя. Такого e-mail адреса НЕ СУЩЕСТВУЕТ. По этому все письма отправленные на несуществующие адреса перенаправляем на image_upload@mysite.com. Потом, при считывании почты с этого адреса, парсим заголовки и узнаем на какой адрес изначально было отправлено письмо. Распарсив полученный адрес, узнаем КУДА складывать файлы и кто их залил.
Peer-to-Peer → Perfect dark (Анонимная P2P)
* Perfect Dark — пиринговый файлообменный клиент для Microsoft Windows.
** На данный момент основное заполнение пространства сети занимает Японский контент.
** Данная сеть не зависит от работоспособности серверов, так как в них нету надобности.
** Анонимность заключается в том что никто не знает что именно вы качаете, и что выкладываете.
** Используются технологии шифрования
Facebook → Загружаем из Picasa прямо в Facebook
Только что завершился грандиозный проект, посвященный объединению Германии, о котором я напишу попозже, и в котором я имел счастье принять участие. а именно повторить маршрут 20 летней давности…
Естественно полно фотографий. Как всегда зашел в Facebook, чтобы хоть кинуть пару фоток.
Ну не хотелось мне делать это вручную, хотелось чтобы Picasa сама это сделала… начал уже ворчать, как вдруг подумал: а может в гугле посмотреть?
и правда поиск Picasa to Facebook дал много ссылок, ссылающихся на PicasaUploader
короче, что с этим делать:
Это как установить, а вот как пользоваться — это вообще проще:
Кросспост
Естественно полно фотографий. Как всегда зашел в Facebook, чтобы хоть кинуть пару фоток.
Ну не хотелось мне делать это вручную, хотелось чтобы Picasa сама это сделала… начал уже ворчать, как вдруг подумал: а может в гугле посмотреть?
и правда поиск Picasa to Facebook дал много ссылок, ссылающихся на PicasaUploader
короче, что с этим делать:
- Устанавливаем Picasa, если пока не сделали, то всегда сможете сделать это.
- Устанавливаем Плагин.
- В появившемся списке добавляем новую кнопку на панель кнопок
Это как установить, а вот как пользоваться — это вообще проще:
- Выбираем какие фотографии хотим загрузить… для нескольких, в левом нижнем углу нажимаем Hold
- Нажимаем на кнопку Facebook. нам придется залогиниться, чтобы суметь загрузить фотографии в наш профайл.
- Выбираем Альбом или создаем новый
- Нажимаем на Upload...
- После того как программа загрузить фотографии на Facebook, мы передем на страницу подтверждения.
- ВСЕ!
Кросспост
Zend Framework → Загрузка и переименование файлов
Статья написана для тех, кто уже хоть немного знаком с архитектурой Zend Framework. Если кому-нибудь будет интересно — опишу работу с формами более подробно в отдельной статье.
Для загрузки файлов на сервер с помощью форм в Zend Framework Form есть элемент Zend_Form_Element_File. У него есть фильтр «Rename», который позволяет переименовать закачаный файл. Но есть минус — мы не можем просто указать новое имя для файла, чтобы сохранилось его расширение. Как это сделать? А как быть, если мы используем setMultiFile?
Для загрузки файлов на сервер с помощью форм в Zend Framework Form есть элемент Zend_Form_Element_File. У него есть фильтр «Rename», который позволяет переименовать закачаный файл. Но есть минус — мы не можем просто указать новое имя для файла, чтобы сохранилось его расширение. Как это сделать? А как быть, если мы используем setMultiFile?
Я пиарюсь → Pict.com — новая версия хостинга изображений.
Всем привет!
Сегодня была запущена новая версия бесплатного хостинга изображений Pict.com.
Надеемся, что обновленный Pict.com понравится Хабравчанам.
Сегодня была запущена новая версия бесплатного хостинга изображений Pict.com.
Надеемся, что обновленный Pict.com понравится Хабравчанам.
jQuery → ajax загрузка нескольких файлов с php формой
Как-то для личных целей мне понадобилось сделать ajax загрузку сразу нескольких файлов. Но хотелось сделать это красиво и удобно.
Для этой задачи я выбрал горячо мной любимый jquery и несколько плагинов к нему.
Для этой задачи я выбрал горячо мной любимый jquery и несколько плагинов к нему.
Nginx → Nginx UploadProgress Module
Модуль для nginx, с помощью которого достаточно просто мониторить прогресс загрузки файлов на сервер. Ранее были подобные решения, через модули к php, ruby, через стороние скрипты, flash объекты итп. Автор предлагает универсальное решение на уровне web сервера. Подробную информацию и инструкции вы можете найти на wiki.codemongers.com (кстати, один из лучших проектов, посвященных nginx`у). Тут я хотел обратить внимание на другое.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т. к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т. к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.
update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т. к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т. к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.
update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.
