Основные советы по этой теме пробовал, не помогло...
После отправки файла, какое-то время "оно" думает, потом у отправляющего в чате возникает сообщение:
undefined
undefined
Файл физически нигде не появляется, хотя получатель видит на него ссылку (разумеется она не работает).
С правами на папки проблем нет, менял пару тем, дефолтных, та же история. Пробовал версию 10 и 11.
Хостинг на Server 2012.
Там есть строка
$url_file = get_bloginfo('wpurl').'/wp-content/uploads/temp-files/'.$arch_name;
wpurl на "." переопределить нельзя, т.е. она всегда (в моем случае) формирует мусор.
Меняем на
$url_file = $arch_name;
Файл проскакивает во временной папке, потом исчезает в никуда.
в таблице rcl_private_message правильная, полагаю, строка (C:PHP_TMPuploadphp3B8A.tmp.zip).
Буду много думать...
В базу ложится $url_file , она уже кривая.
Вся кривизна начинается на этапе:
$mime = explode('/',$_FILES['filedata']['type']);
$name = explode('/',$_FILES['filedata']['tmp_name']);
$cnt = count($name);
$t_name = $name[--$cnt];
Вот тут $t_name получает полный путь и имя (например C:PHP_TMPuploadphpB421.tmp)
Но, судя по логике кода, ожидается phpB421.tmp
У меня нет возможности проверить под Linux...
Походу частично починил 
Заменил слеш на двойной
$mime = explode('\',$_FILES['filedata']['type']);
$name = explode('\',$_FILES['filedata']['tmp_name']);
Путь в базе формируется корректно, но временный файл остается во временной папке.
Поправка: временный файл оседает в wp-contentuploadstemp-files
При этом сылка на него, которая выдается в download.php - неверна
В базе данных абсолютная ссылка на файл правильная (полный URL)
Едем далее
download.php
$url_ar = explode('\',$path_parts['dirname']);
Проблема решена! 
Однако надо заметить - наш файл зазипован, даже если это картинка.
Как решить проблему типа файлов не знаю (все проходит в ZIP). проверка типов не работает в принципе, т.к. тип файла для картинки идет application/octet-stream
Т.е. на хостинге под Windows все файлы будут в ZIP
ДЛЯ ТЕХ, КТО БУДЕТ РЕШАТЬ ПРОБЛЕМУ ФАЙЛОВ В ПРИВАТАХ:
Если у вас хостинг на Windows Server - проблема в слешах, заменяйте их:
в скриптах upload-file.php и download.php
менять explode('/' на explode('\'
не думаю, что ваше решение является корректным, для вас было достаточно просто не прогонять путь на файл через функцию explode, с вашими коррективами присутствие этой функции становиться вообще неоправданным.
И дело вообще не в слешах, explode раскладывает путь на массив, чтобы получить его отдельные части, а поместив в функцию два слеша по вашему совету этого вообще происходить не будет. Ваши коррективы не дают скрипту определить точный тип файла и он будет его всегда архивировать в zip.
Советовать другим править код также в корне не верно.
Надо было все-таки разобраться с сервером, а не подбивать код под него.
Много, очень много перерыл, но не нашел способа заставить PHP в Windows перевернуть слеши путей. В итоге ушел от explode('\'
Предлагаю другой вариант, который позволит о проблеме забыть - модифицировать исходник проекта:
в download.php включить строку
$path_parts['dirname']=ereg_replace('\\','/',$path_parts['dirname']); // Обеспечивает совместимость кода с Windows Server
перед строкой
$url_ar = explode('/',$path_parts['dirname']);
в upload-file.php включить строку
$_FILES['filedata']['tmp_name']=ereg_replace('\\','/',$_FILES['filedata']['tmp_name']); // Обеспечивает совместимость кода с Windows Server
перед строкой
$mime = explode('/',$_FILES['filedata']['type']);
Преимущества - не надо патчить файл самому после каждого обновления, код становится работоспособным в любой среде.
Про косяк с mime ничего не могу сказать, пока. Будем искать...
Поправка - беру паузу. Работоспособность закачки звуковкартиноквидео зависит от браузера.
В текущем варианте под хромом перестала работать закачка картинок совсем (до этого проверял в IE, соответственно application/octet-stream - это он отдавал).
Скрипт тут не причем. Тик контента отдает браузер.
Добавка строки
$_FILES['filedata']['type']=ereg_replace('\\','/',$_FILES['filedata']['type']); // Обеспечивает совместимость кода с Windows Server
позволяет закачивать файлы и в хроме, однако картинки тоже оборачиваются в ZIP
Скрипт не должен зазиповывать файлы типа audio, image и video это главное. Как будет отдавать браузер вопрос не стоит, это их прихоти и не столь важно, важно, что файлы этого типа не придется распаковывать и можно будет сразу открыть. Поэтому надо учитывать определение типа из mime загружаемого файла и учитывать его при дальнейшей обработке.
Укажите к какому виду приходит путь до файла после обработки через ereg_replace? Подойдет ли такой вариант для работы на других серверах?
Андрей Plechev сказал(а)
Укажите к какому виду приходит путь до файла после обработки через ereg_replace? Подойдет ли такой вариант для работы на других серверах?
Формируется полный АБСОЛЮТНЫЙ путь до файла с временным именем. В этом пути слеши "верные", т.е. под *nix средой должно тоже исполняться корректно.
Точнее даже так - все преобразования могут происходить только в Windows, в среде *nix это пустой балласт, который ничего не заменяет. Скрипт становится кроссплатформенным и в этой части начинает работать.
Едем дальше...
Строка $mime = explode('/',$_FILES['filedata']['type']);
Возвращает значение, зависящее от браузера клиента. Не от фактического типа реально закачанного файла (во всяком случае у меня).
Если у клиента IE, то $mime всегда одинаковая, т.е. на выхлопе всегда ZIP.
Если у клиента хром, то $mime принимает верное значение. Но тут вылезает следующая подлянка:
После строки if($mime[0]!='video'&&$mime[0]!='image'&&$mime[0]!='audio'){
выполняется вторая часть условия (переместить без архивации), но тут, при выполнении:
move_uploaded_file($_FILES['filedata']['tmp_name'], $path_temp.$filename);
Файл не перемещается. При чем аргументы верные оба, и проверял с обоими типами слешей.
Например такие C:PHP_TMPuploadphp1962.tmp и C:inetpubprojectorhunterwp-contentuploadstemp-filesphp1962.tmp.jpg
В мануалах по функции пишут, что она сама проверяет корректность (файл не может перемещаться куда попало и должен быть закачанным через PHP).
Видимо эта проверка запрещает перенос (других причин придумать не могу).
Соответственно картина - если мы кидаем через приват архив - он проходит в любом браузере.
Если мы кидаем картинку в IЕ - она проходит, завернутая в ZIP.
Если кидаем в Хроме - ее тип корректно отдается, она не архивируется, но и не перемещается. Все остальные части отрабатывают верно (URL в БД, скачка получателем, удаление после и т.д.) за одним исключением - физически файла нигде нет.
Это очевидно, Кэп!
А как жить дальше?
Ну в любом случае - замена на COPY вопрос решила, все работает теперь как надо (то, что файл копируется, а не перемещается - не суть, по старому адресу он убивается по завершению скрипта). Если будет включено в исходик - буду счастлив.
Хотелось создать кросплатформенный скрипт, чтоб не патчить с каждой новой версией исходник... Но если нет - и черт с ним!
Вообще цель моя - покупка и прикручивание фриланс-плагина, как закончу юридическую волокиту. Там, полагаю будут те же проблемы с файлами. Принципиально важно, что решение существует, пусть и с костылями.
хотелось бы конечно максимально использовать функционал самого ВП даже в вопросах копирования файлов, что то с трудом вериться, что в функции move_uploaded_file не предусмотрели подводных камней с подобными серваками, по поводу слешей поправить можно будет, вроде как функция wp_normalize_path (если не ошибся) должна с этим справиться.
