Sngrl.ru

Шалом! Довелось мне тут давеча поработать с движком Dating Pro – если кто не знает, такая большая тяжелая шестеренка для организации сайта знакомств. Не смотря на свои размеры (дистрибутив более 100мб) – работает весьма шустро и не сравнится с джумлой в связке с кривыми модулями от испанских разработчиков-индусов  (был опыт, ага). Так вот, проблема была в том, что при попытке обновить аватарочку вываливалось сообщение об ошибке – попросили исправить.

Начал разбираться. В админке нашлась галочка «Модерировать загружаемые изображения», однако там было все в порядке. С «владельцем» и правами доступа/записи на временную директорию и на директорию назначения самого движка все тоже было в норме. Полез копаться в коде. Выяснилось вот что: загрузка файла происходила нормально, после чего движок пытался изменить размер загруженного изображения ДО его переноса из временной папки темп (общей для всего сервера), т.е. открыть картинку, изменить ее размер и записать обратно. После этого видимо все и ломалось. Показалось мне, не по феншую это, и проблема могла исходить именно отсюда. Для этого сразу после кода загрузки файла, перед всеми остальными действиями движка, я вставил вот такой код:

# --- Перемещаем загруженый файл во временную папку --- #
$new_file_name = $this->GetNewFileName($upload["name"], $id_user);
$upload_path = $_SERVER['DOCUMENT_ROOT']."/images_tmp/".$new_file_name;
$moved = move_uploaded_file($upload["tmp_name"], $upload_path);
$upload["tmp_name"] = $upload_path;
# ----------------------------------------------------- #

Что здесь происходит? В первой строке генерируем имя нового файла, используя стандартную функцию движка – здесь ничего особенного. В массиве $upload хранятся данные по загруженному файлу. Далее собираем полный путь до временной директории в каталоге самого движка чтобы засунуть туда нашу картинку – после всех действий мы ее отсюда удалим. В третьей строке, с помощью стандартной пхп-шной функции переносим загруженный файл из общей папки серевера (например, /var/tmp) в нашу временную директорию. И последней строкой меняем в массиве полный путь с именем загруженного файла на новый, только что созданный. Делается это потому, что далее движок для всех своих действий (ресайза, создания картинок для предпросмотра, большой и маленькой аватарок) использует именно этот массив, и получается что теперь все действия производятся над файлом в локальной директории сайта, где он имеет полные права и может хозяйничать там как хочет. В теории, и во временной папке он имеет достаточные права – но вот как-то так.

После проделанных действий все заработало как надо. Осталось только после всех телодвижений движка удалить файл из временной директории:

# --- удаляем картинку из временной папки --- #
unlink($upload["tmp_name"]);
# ------------------------------------------- #

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

Учитесь разбираться в чужом коде – пригодится

Привет. Пишу редко – времени совсем мало. А может просто лень-матушка

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

Есть у меня музыкальный сайт, с поиска идет порядка 1k посетителей в день. И вот, в очередной раз просматривая статистику LiveInternet и проверяя единичные запросы с удивлением обнаруживаю, что по одному из них Яндекс предлагает пользователю перейти на файл *.txt в одной из служебных директорий сайта. Надо сказать, что в robots.txt эта дира не была закрыта от ПСов, но и ссылок на нее нигде не было и не могло быть! Там лежат 2-3 txt-файлика, куда пишутся логи и запросы посетителей. А поскольку сайт музыкальный, то в один из файлов попадали названия треков и исполнителей. Вот эту сборную солянку и раскопал Яндекс, с удовольствием скушал и вываливал в результаты поиска по низкочастотным кеям. Причем, перейдя по этой ссылке, пользователь получал файл в 25 мегабайт, абсолютно никак не структурированный и не форматированный.

Во дела, подумал я. Ведь чел, заходя на сайт и видя такой бардак – сразу сбежит! Плюс к этому, я не знаю сколько таких людей попадает на сайт и скольких потенциальных посетителей я лишаюсь, т.к. кода статистики ЛИ там по просту нет, а с парсерами логов веб-сервера заморачиваться не хотелось.

Что я сделал? Первым делом закрыл директорию от индексации в robots.txt, а потом подумал – стоп! Траф есть – зачем его обрубать? Убрал запрет и сделал следующее…

В файле .htaccess прописал RewriteRule с этого txt-шника на файл с php-кодом. Далее, препарировал достаточно известный модуль для DLE «Переходы», вырезал из него код для определения поискового запроса, и если посетитель пришел с какой-либо поисковой системы – генерировал локальный адрес на сайт и редиректил посетителя туда, где он находил то что ему нужно.

Другими словами, если бы при запросе «Джигурда» ПС выдала ссылку на мой txt-шник и пользователь перешел бы по ней, то скрипт, перехватив поисковый запрос («Джигурда»), отправил бы посетителя на… адрес вида «http://site.ru/search/Djigurda».

Проверил – все работает. Следующий нюанс – если к нам забрел поисковый робот, а не посетитель с поиска – показываем ему содержимое txt-файла. Пусть думает, что все так и должно быть

И последний момент – надо же как-то собирать статистику. Т.к. на проекте установлен счетчик LiveInternet – то и сливать посещения нашего txt-шника надо ЛайвИнтернету. Смотрим исходный код счетчика:

<!--LiveInternet counter--><script type="text/javascript"><!--
new Image().src = "//counter.yadro.ru/hit?r"+
escape(document.referrer)+((typeof(screen)=="undefined")?"":
";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth?
screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+
";h"+escape(document.title.substring(0,80))+
";"+Math.random();//--></script><!--/LiveInternet-->

И переносим его на PHP:

$url = "http://site.ru/path_to_dir/txt_file.txt";

$li = "http://counter.yadro.ru/hit?q;r".urlencode($_SERVER["HTTP_REFERER"]).";s100*100*8;u".urlencode($url).";huniquequeries;0.".rand(999999999, 9999999999);

file_get_contents($li);

Разрешение экрана пользователя PHP определять не умеет, поэтому ставим 100х100 – проще будет отслеживать статистику. УРЛ страницы на первое время оставляем оригинальный – чтобы понять, много ли туда народу попадает. С курл’ом заморачиваться не было необходимости, поэтому обошлось малой кровью – file_get_contents(), благо на своем сервере можно делать все что хочешь. Для надежности все же сделал отдельно локальное логирование посещений.

Вот собственно и все. Заливаем файлы и ждем. В итоге за сутки в данный файл тыкнулось порядка 100 посетителей. Немного? 10% от дневного трафа. Файл стал самой частой точкой входа по статистике LI.

Вот такой вот эксперимент, возникший случайно и на ровном месте.  Экспериментируйте, находите нестандартные решения