Разработка

Небольшая хитрость

Преамбула

Шеф сегодня дал задание выбросить на сайт 180 фотографий.
Фотографии требовалось оформить в виде превьюх с увеличением по клику + текст статьи сверху.

Анамнез

У меня не было под рукой модуля с мультизагрузкой и генерацией превьюшек на лету, поэтому пришлось искать «костыли». Но на сайте стояла LightBox и IMCE (если нужна статья по настройке связки этих модулей + визивига, то отпишите в камментах)

Решение

Засовываем в пикасу папку и исходниками. Генерим превьюшки. Открываем IDE пишем код

<?php
$txt=fopen('code.txt',w);
if ($handle = opendir(«C:\work\ВНИИНМАШ\СЛАЙД-ШОУ ДЛЯ САЙТА ВНИИНМАШ\small_750px“)) 
{
  echo "<p>Файлы:<br>“;
 
  while (false !== ($file = readdir($handle))) {
      echo "$file<br>;
      $code="<a href=\“http://intranet/sites/default/files/piter_nano_2011/".$file.“\" rel=\“lightbox\"><img src=\“http://intranet/sites/default/files/piter_nano_2011/180/preview_».$file\"></a> ";
      fwrite($txt,$code);
  }
 
  closedir($handle);
}
fclose($txt);
?>

Скрипт генерит код для вставки превьюшек для статьи. Превьюшки открываются лайтбоксом, показывая оригинал фотографии.

 
 
22.06.2011 — 15:07

Комментарии (27)

Аватар пользователя Stan
22.06.2011 — 20:16
0
 
 

Перенесите в блог «Разработка»

Аватар пользователя NaZg
22.06.2011 — 20:34
0
 
 

done

Аватар пользователя brainstorm
22.06.2011 — 22:29
1
 
 

с advimage + advupload такой фокус возможен.
у нас там правда пошел спор с порядком картинок(в окнах правок новые картинки впереди) — но это детали. можно прицепить к ноде и вывести cck виджетом слегка его темиззировав касательно лайтбокса :)
если это 6ка.

либо голый advupload + одинарная нода с множественным imagefield — вас бы скорее спасло :)

PS. есть там недочеты, но мы работаем над этим :)

Аватар пользователя NaZg
22.06.2011 — 22:32
0
 
 

> либо голый advupload + одинарная нода с множественным imagefield — вас бы скорее спасло :)
фоты туда руками забивать?

Аватар пользователя brainstorm
22.06.2011 — 22:40
1
 
 

там заливайка на флеше от plupload.com. фоты выбрать в окне выбора файлов, надавить Start upload и тупо ждать пока все зальецо :)

Я жеж видево давал как оно пашет. http://youtu.be/NtpQywOk6Fw

И поддерживает работу по принципу 1 файл — 1 нода и много файлов в одну ноду.

Аватар пользователя NaZg
23.06.2011 — 06:08
0
 
 

гляну
спасибо

Аватар пользователя PVasili
23.06.2011 — 12:52
-1
 
 

Посмотрите, по мультизагрузке есть штук 5 модулей. От flash до java.

Аватар пользователя Stan
23.06.2011 — 14:50
3
 
 

Почти на всех своих проектах использую или Plupload integration, или Uploadify.

Как вариант для использования вставки изображений в редактор такая связка:

Для клиентов эта связка оптимальна.

Плюсы: работа с Imagecache, быстрая загрузка и вставка

Аватар пользователя brainstorm
23.06.2011 — 18:06
0
 
 

модуль plupload не содержит никакой нормальной валидации — при желании сервер можно завалить временными файлами. у меня это учтено.
uploadify — та же картина.

Их пользовать можно но нельзя доверять «чужакам».
WYSIWYG image upload, IMCE и прочие — не ведут учета «чья картинка потерялась» :)
В files лежит кипа файлов, но ты не знаешь как с ними жить — стереть нельзя, к чему относятся — неизвестно — это бесит. Ненормально — если стер статью а файлы остались. Нормально = если стер статью — и файлы либо удалились либо есть «песочница» где их можно удалить.

Аватар пользователя Stan
23.06.2011 — 18:24
0
 
 

В files лежит кипа файлов, но ты не знаешь как с ними жить — стереть нельзя, к чему относятся — неизвестно — это бесит.

Так есть Filefield paths -)

Аватар пользователя brainstorm
23.06.2011 — 18:35
0
 
 

ты не понял. в случае IMCE например нет никаких записей в БД о загруженных через него файлах. вообще нет.
насчет модулей которые альтерят пути — там свои неудобства выпадают.

Аватар пользователя FORTIS
24.06.2011 — 21:22
1
 
 

есть, IMCE покажет только те файлы которые были загружены через него и имеют fid в базе. залив через фтп файлы ты не увидишь их в imce

Аватар пользователя brainstorm
25.06.2011 — 16:11
0
 
 

IMCE не пишет в таблицу files вообще то :)
насколько помню. пойду гляну внутрь.

Аватар пользователя brainstorm
25.06.2011 — 16:13
0
 
 

надо же. таки хранит. но связок с документами не держит.
что очень плохо, я считаю.

Аватар пользователя FORTIS
26.06.2011 — 13:44
0
 
 

это да, сталкивался

Аватар пользователя brainstorm
23.06.2011 — 18:07
0
 
 

а вот интегрировать загружайку с CCK виджетом — процесс таки оченьь муторный. Изза запутанной структуры самих CCK.

Аватар пользователя FORTIS
24.06.2011 — 21:16
0
 
 

а чем это лучше связки wysiwyg_imagefield + insert + image_resize_filter?
просто мнение интересует

Аватар пользователя brainstorm
26.06.2011 — 00:35
1
 
 

http://drupal.org/node/950564
OMG. он ресайз делает минуя imagecache? o_O

Аватар пользователя xandeadx
26.06.2011 — 00:59
1
 
 

imagecache подходит когда размеры известны заранее, с image_resize_filter можно указать любой размер

Аватар пользователя brainstorm
26.06.2011 — 09:26
1
 
 

imagecache подходит и когда размеры неизвестны.
там есть хуки для задания своего пресеета и картинку можно построить по параметрам из бд.

даже есть модули на эту тему :)

в данном случае они вместо использования Imagecache генерят картинку сами при показе ноды — насколько я понял по сырцу. естессно процесс требует больше памяти чем Imagecache который делает это по хандлеру меню :)

Аватар пользователя FORTIS
26.06.2011 — 13:43
0
 
 

не уверен, потом присмотрюсь. но помоему оно при редактировании ноды и зменении размера картинки через свой фильтр как раз и генерирует с имеджкешем новый размер, не при показе, а при сабмите

Аватар пользователя brainstorm
26.06.2011 — 14:18
0
 
 

там имажкеша вообще нет.
получается — рабочая память всех модулей + память на конвертирование. надо в 2 раза больше памяти на процесс.
имажкеш решает но они решили что умнее.

Аватар пользователя xandeadx
26.06.2011 — 23:53
0
 
 

простейший пример можно? если imagecache будет ресайзить картинки по параметрам из url то это прекрасный способ вальнуть сервер за пару часов. по другому же он работать не умеет, пресет не может быть динамическим, точнее может, но ограничен своим хэндлером

Аватар пользователя brainstorm
27.06.2011 — 01:41
0
 
 

пример? пишешь свой хук для имажкеша который говорит что есть пресет для твоего модуля.
пишешь свой обработчик для этого пресета — там это можно.

для каждого файла хранишь «параметры» ресайза в отдельной табличке.
ну да, подчистку предусмотреть для случая если это был временной файл.

вот и все. :)

Аватар пользователя andypost
24.06.2011 — 15:37
0
 
 

Илья грамотно заметил — все файлы в дру являются managed & UNMANAGED, последние как раз и оставляют мусор при удалении, так как не имеют привязки к сущностям ядра.

А вот как бороться с мусором во временных файлах — хз, тут релаьно возможен вариант атаки через заливку мегатонны файлов без создания привязки им! Интересно обсудить варианты ограничения объема временных файлов.

Аватар пользователя brainstorm
25.06.2011 — 16:58
1
 
 

я у себя просто решил.
у меня модуль предназначен для загрузки больших файлов. до двух гиг. например видео.
всявзи с этим копировать из временного файла как делает это друпал мне было низя.
представьте копирование 600 мегабайт из файла в файл на УЖЕ загруженном хосте.(многие тут начнут петь про RAID и всякие SCSI) но я решил что из этого вытекает требование — файл должен формироваться через переименование.

1. Т.е. временной каталог модуля на той же ФС что и каталог файлов сайта а именно закопан в нем.
2. при загрузке могут происходить сбои. то есть в этом временном каталоге 100% будет мусор от сбоев связи и тд(у текущего клиента показало что так и есть порой.). значит кроме отработчика крона мой модуль должен ловить все временные файлы из этой подпапки касающиеся загрузки. и ТЕРЕТЬ ИХ. что и происходит.

таким образом я и решил проблему пустого засирания винта сервера ненужным г-ном.

То как это сделано в CCK — это последствия того что файлы создаются РАНЬШЕ создания ноды. и кстати формы CCK ПОЗВОЛЯЮТ зафлудить сервак. там нет подчистки предыдущего. нет ее по простой причине. те файлы тоже временные. и МОГУТ БЫТЬ НУЖНЫ В ТЕКУЩЕМ РЕДАКТИРОВАНИИ.

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

Аватар пользователя andypost
26.06.2011 — 21:06
0
 
 

Илья, согласен с тобой частично. Эта дилема на самом деле зависит от конкретных задач и решений.

Заливаемые файлы всяко льются во временную папку PHP и ядро не имеет к этому никакого отношения, так что папка всяко будет засираться… скорее на сервере нужно выставлять грамотную её чисту.

Если речь идет о загрузке файла как сущности, имхо тут лучше копать в сторону модуля Media (единой библиотеки файлов) с последущей привязкой его куда нужно :)

Твое решение тоже частично, так как учитывает только пост-загрузку… но не этап флуда запросов к серверу, именно тут и нужно ограничение на объем загружаемого файла ибо /tmp всяко не резиновый…

Когда файл(ы) загружается посредством любой формы ядра, то неминуемо есть вариант, что PHP завершится по таймауту — транзакция для таблиц откатится, а вот копирование/перемещение файла будет в неопределенном состоянии.

Так что с таким количеством граблей/прокладок лучше вообще не загружать файлы :)