UnitDev

Ну конечно, 10 минут никак не реагировать на странице загрузки файлов, призывая пользователя подумать о том что всё повисло и закрыть вкладку, это хорошая реализация. Сразу видны мировые практики. Конечно, отвал монтирования и просто сбой загрузки файла через PHP и нормальная отработка исключения, это одно и тоже, совсем нет разницы. Вы смешали и CloudFlare, и примонтирование FTP как путь в никсах, чего в моём сообщении не было. Ну вот, от S3 одни проблемы, а вы так яростного его защищаете, что отказываетесь от нормальной реализации при FTP варианте, в угоду своему S3

Потому что то, что сделал разработчик не логично, разделить цифровые товары и физические на два модуля. Это как минимум странно. Его просили сделать физические товары у старого модуля, он выпустил зачем то новый, причём насколько я понял (может конечно не прав), они вроде как делают одно и тоже, только для разных типов товаров.

Если это единственный способ заливать крупные файлы с CloudFlare, то что поделать то? Ну либо как наиболее нормальный вариант который большинство и использует, переносить файлы порционно по крону, тогда это вообще в фоне будет работать и это самый быстрый вариант для пользователя. Я давно смотрю на запросы пользователей, и все хором говорят что S3 это дорого, там можно хранить разве что какие то небольшие объёмы и в очень специфичных ситуациях. Посмотрите первые 3-5 страницы общей ветки форума. То что S3 пользуются наверное сотые доли процента от тех кто вообще пользуется внешним хри

На нормально сконфигурированном FTP можно дозаписывать файлы. Будем честны, S3 используют единицы, потому что это сильно дороже FTP, никто не хранит терабайты на S3 и не отдаёт сотни террабайт трафика с него, на эти деньги можно несколько хороших файловых серверов организовать, и ещё даже останется приличная сумма. То что S3 был добавлен потому что это модно и громко, и потому что в опен-сорс коде он уже был, оно понятно, но это не значит, что им по факту кто то сильно пользуется, даже этот форум показывает настрой пользователей на FTP вариант. Вы же поняли прекрасно, что имелось в

Действительно, спутал с модулем цифровых товаров, только не понятно зачем нужно было делать отдельный модуль, когда продажа цифровых товаров и физических, явно должна быть реализована в рамках одного модуля магазина. Если модуль будет как минимум не хуже того что когда то продавал sander, то потенциал есть, и надо будет прикупить.

Т.е. будет скрипт на FTP хостинге который будет дёргать DLE? Нужно ещё что бы можно было остальные алгоритмы хеширования добавить легко плагином, а не жестко зашиваться сугубо под MD5. По факту не важно как он поступает, файл всё равно обрабатывается DLE и в этот момент можно вычислить его хэш, правда не помню, целиком ли он поступает на сайт при скачивании с удалённого сервера и переноса его на удалённый, нужно код смотреть. Ещё есть одна проблема которую заметил при тестах, если файл слишком жирный, то время его передачи с DLE на удалённое хранилище слишком большое, и если исполь

Может и купило всего 3 человека, потому что он не доделан до логического завершения функционала? По моему там в комментариях одни запросы от пользователей, и предложение оплатить доработки дополнительно.

Модуль никак не развивается и по факту заброшен.

Всё таки будет исправлено? А как если не секрет? Подсчёт на стороне сервера где DLE? Скрипт на хостинге файлового хранилища? Надо понимать, либо доделывать до конца нормальную реализацию и много в чём переписывать код DLE, или всё таки коробочное решение устроит. Если уж решили доделывать функционал до ума, подумайте над аналогом раздела перестроения публикаций, только для переноса файлов и изображений на внешнее хранилище (порционный перенос файлов за один проход скрипта), ну и как многие говорили уже тут, нужно более одного хранилища, для той же балансировки нагрузки по трафику хотя

Вы точно прочитали верно моё сообщение? То что вы считаете MD5 файлов на удалённом сервере по своему волшебному алгоритму, который с остальным миром не состыкуется, это проблема DLE, а не остального мира. Причём возможность нормального подсчёта хэша есть, просто вам лень было нормально это реализовывать.

Практичней всего любой хостинг/сервер с FTP и HTTPS. Но имейте ввиду, что DLE не правильно считает MD5 хэш файлов (и скрывает это везде), загружаемых на удалённое хранилище, и @celsoft не видит в этом ничего такого, для него всё в норме.

С каких пор у md5 вариации начались? md5 файла это не то же самое что md5 от размера файла. Пока файл собирается из чанков в /uploads/files/, когда он дособран, его можно посчитать там, хотя правильнее всего было бы посчитать уже после загрузки на удалённый хост, но для этого его нужно либо выгружать обратно для подсчёта, либо на стороне удалённого хоста уже разместить служебный php файл, но так как сделано сейчас, это именно баг, потому что никакого md5 файла не подсчитывается, и он может быть таким же битым, и иметь такой же размер, тем более что при отправки и разбиение на чанки, не

@celsoft Заметил особенность, что хеши не совпадают, если файл залит на удалённый хост. $size = DLEFiles::Size( $this->upload_path . FOLDER_PREFIX . $uploaded_filename ); if ( $driver AND !DLEFiles::$remote_error ) { $http_url = $config['remote_url']; $md5 = md5( $size ); } else { $http_url = $config['http_home_url'] . "uploads/"; $md5 = md5_file( ROOT_DIR . "/uploads/" . $this->upload_path. FOLDER_PREFIX . $uploaded_filename ); $driver = 0; } Тут как бы в коде один хеш считается от размера, а второй реальный хеш файла. Этот баг так и был задуман? Можно же нормально посчит