В настройках php. Пункт php_max_upload_size ограничивает размер (2mb по умолчанию), а script_execution_time - время исполнения (30 sec by default). Похоже у вВас второй случай:за 30 сек скрипт просто не успевает положить файл.
Есть такой скрипт [url=http://sypex.net/]Sypex Dumper[/url], он обходит это ограничение. Закачивая поэтапно (не знаю как он это делает, но работает). Он создан для заливки бэкапа базы данных на сервер посредством php. Размер бэкапа неограничен (разработчики говарят о сотнях мегабайт). Если посмотреть код и реалтзовать это в Друпале, то был бы неплохой модуль.
Не нашёл, где написано о закачке сотен мегабайт (плохо искал?).
Если это:
"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт), в связи с этим вся работа с файлами бекапа осуществляется по FTP, но download возможен и с помощью менеджера загрузки (Download Master, Reget и др.);",
то тут ни слова про закачку.
[b]"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт)"[/b]
да именно это я и имел ввиду... учитывая то, что скрипт как раз и занимается тем, что делает бэкап или наоборот восстанавливает из бэкапа, то это как раз работа с базой данных.
Щас поставил себе на локалхост и мажордомский хостинг. Все пучком. А удобно как. Все просто, как автомат Калашникова...
Единственно, у кого на хостинге MySQL откликается не на localhost, а на какой-то ip-адрес, нужно руками поправить одну строку в кишках dumper.php. Ну, друпальцам это как пальцем...
А, забыл сказать. Это всего лишь 1 файл на php, размером около 30 кбайт :). Специализированные штуки рулят...
Не хватает одной кнопки - "Backup ВСЕХ БАЗ!" Но это уже зависит...
Забыл сказать - utf8 нужно указать также вручную, в теле скрипта. По умолчанию там 1251, что для друпальцев болезненно, местами...
p.s. По мере юзанья выяснил пока такое:
Нормальное восстановление Друпала получилось у меня только когда я "отбросил" из списка пакуемых при бекапе таблиц
^cache, ^locales*, ^search*
Иначе постоянно какие-то ошибки с duplicate entries.
p.p.s. На хостинге utf-8 пакуется и восстанавливается нормально. На Денвере (знаю, знаю, не кидайтесь табуретками...) восстанавливается с крякозябрами.
to B.X
Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP).
Как это может помочь в заливке больших файлов из броузера на сервер и что предлагается реализовать для Drupal?
to marazmus
Кодировка 1251 в скрипте указана только для странички закачки. Её смена принципиальна для работы скрипта/дампа база?
Кодировка 1251 в скрипте указана только для странички закачки. Её смена принципиальна для работы скрипта/дампа база?
Кодировка принципиальна!
Оставляем 1251 в скрипте dumper.php и делаем с его помощью дамп базы друпала, что в utf-8. Глядим внутрь дампа - все тексты в 1251
Естественно, при восстановлении имеем проблемы с кодировкой контента.
Ставим в скрипте dumper.php кодировку utf8. Дамп базы сливается в utf8, и, соответственно, восстанавливается корректно.
Так что для манипуляций с utf8-дампами нужно править dumper.php, проставляя ему utf8.
Да и коммент в скрипте прямо говорит:
// Кодировка данных базы данных
define('CHARSET', 'cp1251');
Quote:
Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP).
Как это может помочь в заливке больших файлов из броузера на сервер и что предлагается реализовать для Drupal?
Извините, что вмешиваюсь.
Dan, просто попробуй - это всего лишь 30-килобайтный файл, который работает даже на Денвере (знаю, знаю...).
Логика работы такая:
1) При первом запуске dumper.php создает каталог backup "рядом" с собой (т.е. на том уровне, где он "лежит"). В этот каталог скрипт кладет свой конфиг, историю операций и [b]непосредственно сами дампы[/b]. Т.е. файл дампа формируется на серваке, и там же лежит.
Доступны две операции - бекап и восстановление.
2) При бекапе выбираем БД и тип архивации (bzip2 на максимуме дает наибольшее сжатие). Про прошествии некоторого (но по ощущениям сильно, сильно меньшего, чем через phpMyAdmin) времени скрипт рапортует о завершении. В каталоге backup можно найти файл дампа (архивированный, если была выбрана архивация). Скрипт вежливо предлагает скачать его сразу; ну или можно качнуть его по фтп самостоятельно. Короче, если места много, дампы БД можно складывать на серваке хостера
3) При восстановлении скрипт "смотрит", какие файлы есть в директории backup. Соответственно, если под рукой есть дамп, можно по фтп залить его в этот каталог, а dumper внесет его в список возможных файлов для восстановления. Затем выбираем из списка нужный файл, и жмем кнопку "восстановить". Так же за сильно небольшое время БД восстановлена.
Проверено на Денвере и на хостинге мажордомы. На неделе, как куплю серважовский хостинг, всяко будет проверяться там, уже в "боевых" условиях переезда. Так как через phpMyAdmin свой 30-меговый дамп восстановить так и не смог - даже на локалхосте. А через дампер залил влегкую.
То есть путь получается такой - не через post/get, как phpMyAdmin, а путем "подбирания" файла локально - относительно скрипта. Ведь и скрипт, и дамп базы лежат как бы "локально" - в пределах одного каталога и жесткого диска. А через phpMyAdmin данные "гонятся" по http, по сути. В тонкостях могу ошибаться, не спец.
Насчет самой темы - да, базары про SypexDumper не в тему
Так как автору нужна заливка файлА, а не работа с дампами.
Здесь ничего не могу сказать, не шарю.
Добавлено itnovosti, Пон, 11/09/2006 - 14:41
В настройках php. Пункт php_max_upload_size ограничивает размер (2mb по умолчанию), а script_execution_time - время исполнения (30 sec by default). Похоже у вВас второй случай:за 30 сек скрипт просто не успевает положить файл.
речь идет о
upload_max_filesize
и max_execution_time
[b]"Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP)."[/b]
да, с домашнего компьютера не заливает, но я про это и не говорил... просто если он с сервера может заливать такие размеры, то что мешает это сделать и с компьютера? точно также, скрипт может по частям закачивать на сайт, оттуда этот же скрипт может делать что-то ещё...
короче, просто никто этим не занимался ещё...
[b]"всяко будет проверяться там, уже в “боевых” условиях переезда"[/b]
кстати, я написал в Servage, что phpMyadmin не подходит для восстановления базы данных (и прислал им этот Сипекс Дампекс), они ответили, что разберутся и через некоторое время там появился такой подпункт "import database", не знаю, основан он на этом скрипте или нет... но на Servage уже есть что-то похожее, тоже надо закачать дамп по фтп и он сам импортирует его.
В принципе такое реализуемо через Java-апплет при условии что локально установится пакет, имеющий доступ к файловой системе а для этого в свою очередь требуется подписать его уважаемым сертификатом. У меня по такому принципу пашет JavaFTP клиент на одном серваке. Т.е. при заходе по ссылке стартует апплет с двумя окнами: в левом локальные диски а в правом содержимое FTP сервера. По такой схеме можно реализовать докачку но много гиммора.
ИМХО: проще порезать файл на куски и написать скриптик, который потом эти куски на стороне сервера будет клеить.
[b]хм, как ты себе это представляешь?[/b]
ну например, начинается закачка... php разрешено только положенные (во многих случаях) 2МБ, он их закачивает, но дальше не прерывается, а скажем записывает параметры закачки в какой-нибудь файл, потом завершается, и опять запускается, читает этот файл и продолжает закачивание... и так до тех пор пока полностью не закачает файл...
хотя, вообще-то, чем страдать такое ерундой, лучше использовать для этой цели perl, там нет ограничений (насколько я знаю) на закачивание файла...
[b]2: B.X[/b]
А как, интересно, php скрипт сможет возобновить закачку не с начала файла? Он ведь не имеет доступа к локальной файловой системе а ловит только то что ему передаёт браузер в POST или GET запросе. Т.е. чтобы на php реализовать докачку, это для начала должен уметь браузер. Т.е. самый простой в реализации способ - это резать ручками а на стороне сервера клеить при помощи того-же php. Правда пользователям такой вариант врядле понравится.
да, но это надо всё закачивать самостоятельно, к тому же, как быть с другими пользователями? всем давать доступ к фтп? глупо... скрипт даёт возможность именно не только для тебя, но и для остальных закачивать... да и удобно это, нажал, выбрал, прикрепил...
что мешает на стороне сервера делать всё что угодно? например, делать паузы и запускать цикл одних и тех же действий, только с учётом того, что уже закачено? например, не обязательно же скрипт должен завершаться... он может обрабатывать этот файл (который ему передал браузер) и дальше по тем же параметрам, только закачивать с паузами, например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена...
2: B.X
Повторяю, посмотри как с этим справляются различные инструменты для gallery. Там даже есть reg-файл для WinXP. Не ты первый озаботился этой проблемой (заливкой больших файлов). Прежде чем начинать обсуждение на эту (непростую) тему неплохо ознакомится с существующими инструментами. Имхо
если честно, мне это не нужно... во всяком случае в Друпале и именно сейчас... вопрос поднял не я, просто изложил некоторые идеи, как это можно сделать, реализацию я осилить всё равно не смогу...
[i]...например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена[/i]
В том-то и дело что php_max_upload_size - это максимальный размер запроса типа POST, который можно передавать скрипту PHP. Серверу не важно как скрипт будет обрабатывать файл, важно какой объём он получает в рамках одного запроса со стороны клиента. Т.е. если клиент будет передавать файл размера больше чем разрешено то скрипт не сможет достучаться до той части, которая выходит за область допустимого ибо сервер эти данные просто не примет.
Честно говоря сильно я с AJAX не сталкивался но вот что-то не верится что JavaScript тут поможет ибо нет у него возможности достучаться до локальных файлов пользователя. Хотя может это уже как-то и обошли, но не слышал. Пока видел только решения на базе ActiveX- или Java-апплетов, которыми рулит JavaScript. Т.е. к файловой системе может достучаться апплет а скрипт ему просто говорит куда и сколько.
есть решение, потому что, например, сервис http://www.netvibes.com/ позволяет закачивать через себя файлы во всяком случае и 6 и 8 МБ, но наверняка и больше... он постоен на AJAX, жмёшь кнопочку upload file и просто ждёшь, когда закончит закачивание... да и все эти upload-серверы типа rapidshare.de, тоже как-то работают (хотя они как раз могут использовать perl)...
Думаю что просто их серваки настроены на разрешение приёма таких больших запросов ))
Я у нашего хостера спрашивал, можно-ли этот параметр увеличить, они сказали что хоть пол гига мне поставят но толку от этого не будет. Залить такой файл по POST без единой ошибки практически нереально. Сейчас стоит 32 метра а всё крупное файло лью по ftp. Для основных клиентов сделал ftp аккаунты и установил Java-ftp клиента прям на сайт.
[b]"но толку от этого не будет"[/b]
ну заливают ведь... и полгига и больше... всё это зависит от качества связи, тем более на некоторых таких сервисах поддерживается докачка даже...
php.ini это файл настроек php, если на локалке, на пример у меня, он лежит в корне папки windows (на сервере в /etc/php4/apache2/php.ini), на рабочем сервере, смотря что тебе позволяет делать хостер.
Попробовал увеличить upload_max_filesize до 16M через .htaccess и через sites/default/settings.php. (FreeBSD 6.2, Apache 1.3, php 4, drupal 5)
phpinfo говорит, что переменная изменилась, однако файлы больше 2 МБ по-прежнему не заливаются.
Комментарии
В настройках php. Пункт php_max_upload_size ограничивает размер (2mb по умолчанию), а script_execution_time - время исполнения (30 sec by default). Похоже у вВас второй случай:за 30 сек скрипт просто не успевает положить файл.
Все так. Спасибо. Я думал, что default там upload_max_filesize = 16M
Есть такой скрипт [url=http://sypex.net/]Sypex Dumper[/url], он обходит это ограничение. Закачивая поэтапно (не знаю как он это делает, но работает). Он создан для заливки бэкапа базы данных на сервер посредством php. Размер бэкапа неограничен (разработчики говарят о сотнях мегабайт). Если посмотреть код и реалтзовать это в Друпале, то был бы неплохой модуль.
Не нашёл, где написано о закачке сотен мегабайт (плохо искал?).
Если это:
"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт), в связи с этим вся работа с файлами бекапа осуществляется по FTP, но download возможен и с помощью менеджера загрузки (Download Master, Reget и др.);",
то тут ни слова про закачку.
[b]"работа с базами данных любых размеров (от нескольких килобайт до сотен мегабайт)"[/b]
да именно это я и имел ввиду... учитывая то, что скрипт как раз и занимается тем, что делает бэкап или наоборот восстанавливает из бэкапа, то это как раз работа с базой данных.
Вах, какая штука клевая этот SypexDumper!
Щас поставил себе на локалхост и мажордомский хостинг. Все пучком. А удобно как. Все просто, как автомат Калашникова...
Единственно, у кого на хостинге MySQL откликается не на localhost, а на какой-то ip-адрес, нужно руками поправить одну строку в кишках dumper.php. Ну, друпальцам это как пальцем...
А, забыл сказать. Это всего лишь 1 файл на php, размером около 30 кбайт :). Специализированные штуки рулят...
Не хватает одной кнопки - "Backup ВСЕХ БАЗ!" Но это уже зависит...
Забыл сказать - utf8 нужно указать также вручную, в теле скрипта. По умолчанию там 1251, что для друпальцев болезненно, местами...
p.s. По мере юзанья выяснил пока такое:
Нормальное восстановление Друпала получилось у меня только когда я "отбросил" из списка пакуемых при бекапе таблиц
^cache, ^locales*, ^search*
Иначе постоянно какие-то ошибки с duplicate entries.
p.p.s. На хостинге utf-8 пакуется и восстанавливается нормально. На Денвере (знаю, знаю, не кидайтесь табуретками...) восстанавливается с крякозябрами.
to B.X
Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP).
Как это может помочь в заливке больших файлов из броузера на сервер и что предлагается реализовать для Drupal?
to marazmus
Кодировка 1251 в скрипте указана только для странички закачки. Её смена принципиальна для работы скрипта/дампа база?
Кодировка принципиальна!
Оставляем 1251 в скрипте dumper.php и делаем с его помощью дамп базы друпала, что в utf-8. Глядим внутрь дампа - все тексты в 1251
Естественно, при восстановлении имеем проблемы с кодировкой контента.
Ставим в скрипте dumper.php кодировку utf8. Дамп базы сливается в utf8, и, соответственно, восстанавливается корректно.
Так что для манипуляций с utf8-дампами нужно править dumper.php, проставляя ему utf8.
Да и коммент в скрипте прямо говорит:
Извините, что вмешиваюсь.
Dan, просто попробуй - это всего лишь 30-килобайтный файл, который работает даже на Денвере (знаю, знаю...).
Логика работы такая:
1) При первом запуске dumper.php создает каталог backup "рядом" с собой (т.е. на том уровне, где он "лежит"). В этот каталог скрипт кладет свой конфиг, историю операций и [b]непосредственно сами дампы[/b]. Т.е. файл дампа формируется на серваке, и там же лежит.
Доступны две операции - бекап и восстановление.
2) При бекапе выбираем БД и тип архивации (bzip2 на максимуме дает наибольшее сжатие). Про прошествии некоторого (но по ощущениям сильно, сильно меньшего, чем через phpMyAdmin) времени скрипт рапортует о завершении. В каталоге backup можно найти файл дампа (архивированный, если была выбрана архивация). Скрипт вежливо предлагает скачать его сразу; ну или можно качнуть его по фтп самостоятельно. Короче, если места много, дампы БД можно складывать на серваке хостера
3) При восстановлении скрипт "смотрит", какие файлы есть в директории backup. Соответственно, если под рукой есть дамп, можно по фтп залить его в этот каталог, а dumper внесет его в список возможных файлов для восстановления. Затем выбираем из списка нужный файл, и жмем кнопку "восстановить". Так же за сильно небольшое время БД восстановлена.
Проверено на Денвере и на хостинге мажордомы. На неделе, как куплю серважовский хостинг, всяко будет проверяться там, уже в "боевых" условиях переезда. Так как через phpMyAdmin свой 30-меговый дамп восстановить так и не смог - даже на локалхосте. А через дампер залил влегкую.
То есть путь получается такой - не через post/get, как phpMyAdmin, а путем "подбирания" файла локально - относительно скрипта. Ведь и скрипт, и дамп базы лежат как бы "локально" - в пределах одного каталога и жесткого диска. А через phpMyAdmin данные "гонятся" по http, по сути. В тонкостях могу ошибаться, не спец.
Насчет самой темы - да, базары про SypexDumper не в тему
Так как автору нужна заливка файлА, а не работа с дампами.
Здесь ничего не могу сказать, не шарю.
Но дампер - штука все равно клевая
Все уже работает. Так что автору по этому вопросу больше ничего не нужно )
Народ хочет хлеба и зрелищ!
Тьфу ты...
То есть - Как решена проблема?
Спасибо за информацию, заранее.
речь идет о
upload_max_filesize
и max_execution_time
То есть, по сути, общая проблема - для любого движка, а не только для друпала.
В FAQ бы это или в вики какую...
Это не проблема, а скорее ограничение )
Это не проблема, а скорее ограничение )
"Извините, что вмешиваюсь. Dan, просто попробуй - "
Знаю. Пробовал. Очень нравиться.
"Насчет самой темы - да, базары про SypexDumper не в тему"
Я с этого и начал!
SypexDumper и аплод файлов никак не связаны.
"В FAQ бы это или в вики какую…"
FAQ пишется
[b]"Скрипт ничего на сервер не заливает. Делает дамп и заливает дамп он локально (или FTP)."[/b]
да, с домашнего компьютера не заливает, но я про это и не говорил... просто если он с сервера может заливать такие размеры, то что мешает это сделать и с компьютера? точно также, скрипт может по частям закачивать на сайт, оттуда этот же скрипт может делать что-то ещё...
короче, просто никто этим не занимался ещё...
[b]"всяко будет проверяться там, уже в “боевых” условиях переезда"[/b]
кстати, я написал в Servage, что phpMyadmin не подходит для восстановления базы данных (и прислал им этот Сипекс Дампекс), они ответили, что разберутся и через некоторое время там появился такой подпункт "import database", не знаю, основан он на этом скрипте или нет... но на Servage уже есть что-то похожее, тоже надо закачать дамп по фтп и он сам импортирует его.
"просто если он с сервера может заливать такие размеры, то что мешает это сделать и с компьютера"
хм, как ты себе это представляешь?
В принципе такое реализуемо через Java-апплет при условии что локально установится пакет, имеющий доступ к файловой системе а для этого в свою очередь требуется подписать его уважаемым сертификатом. У меня по такому принципу пашет JavaFTP клиент на одном серваке. Т.е. при заходе по ссылке стартует апплет с двумя окнами: в левом локальные диски а в правом содержимое FTP сервера. По такой схеме можно реализовать докачку но много гиммора.
ИМХО: проще порезать файл на куски и написать скриптик, который потом эти куски на стороне сервера будет клеить.
[b]хм, как ты себе это представляешь?[/b]
ну например, начинается закачка... php разрешено только положенные (во многих случаях) 2МБ, он их закачивает, но дальше не прерывается, а скажем записывает параметры закачки в какой-нибудь файл, потом завершается, и опять запускается, читает этот файл и продолжает закачивание... и так до тех пор пока полностью не закачает файл...
хотя, вообще-то, чем страдать такое ерундой, лучше использовать для этой цели perl, там нет ограничений (насколько я знаю) на закачивание файла...
[b]2: B.X[/b]
А как, интересно, php скрипт сможет возобновить закачку не с начала файла? Он ведь не имеет доступа к локальной файловой системе а ловит только то что ему передаёт браузер в POST или GET запросе. Т.е. чтобы на php реализовать докачку, это для начала должен уметь браузер. Т.е. самый простой в реализации способ - это резать ручками а на стороне сервера клеить при помощи того-же php. Правда пользователям такой вариант врядле понравится.
Лучше работать через FTP. Там вообще никаких ограничений.
ключевой момент - "начинается закачка…"!
см. пост выше, в частности фразу "имеющий доступ к файловой системе".
да, но это надо всё закачивать самостоятельно, к тому же, как быть с другими пользователями? всем давать доступ к фтп? глупо... скрипт даёт возможность именно не только для тебя, но и для остальных закачивать... да и удобно это, нажал, выбрал, прикрепил...
Если эта тема так интересна, можете посмотреть, как реализована закачка больших файлов в gallery.
что мешает на стороне сервера делать всё что угодно? например, делать паузы и запускать цикл одних и тех же действий, только с учётом того, что уже закачено? например, не обязательно же скрипт должен завершаться... он может обрабатывать этот файл (который ему передал браузер) и дальше по тем же параметрам, только закачивать с паузами, например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена...
2: B.X
Повторяю, посмотри как с этим справляются различные инструменты для gallery. Там даже есть reg-файл для WinXP. Не ты первый озаботился этой проблемой (заливкой больших файлов). Прежде чем начинать обсуждение на эту (непростую) тему неплохо ознакомится с существующими инструментами. Имхо
если честно, мне это не нужно... во всяком случае в Друпале и именно сейчас... вопрос поднял не я, просто изложил некоторые идеи, как это можно сделать, реализацию я осилить всё равно не смогу...
может через AJAX уже что-то смудрили? нужно-ведь что-то с докачкой придумать, а то даже и на выделенке не всегда без потерь бывает.
[b]2: B.X[/b]
[i]...например, он этот файл может каждый раз (при начале цикла) закачивать с самого начала, но переходить к той части, которая ещё не загружена[/i]
В том-то и дело что php_max_upload_size - это максимальный размер запроса типа POST, который можно передавать скрипту PHP. Серверу не важно как скрипт будет обрабатывать файл, важно какой объём он получает в рамках одного запроса со стороны клиента. Т.е. если клиент будет передавать файл размера больше чем разрешено то скрипт не сможет достучаться до той части, которая выходит за область допустимого ибо сервер эти данные просто не примет.
хм... ну да, тогда только AJAX и спасёт, ведь насколько мне известно, javascript там тоже присутствует?
Честно говоря сильно я с AJAX не сталкивался но вот что-то не верится что JavaScript тут поможет ибо нет у него возможности достучаться до локальных файлов пользователя. Хотя может это уже как-то и обошли, но не слышал. Пока видел только решения на базе ActiveX- или Java-апплетов, которыми рулит JavaScript. Т.е. к файловой системе может достучаться апплет а скрипт ему просто говорит куда и сколько.
есть решение, потому что, например, сервис http://www.netvibes.com/ позволяет закачивать через себя файлы во всяком случае и 6 и 8 МБ, но наверняка и больше... он постоен на AJAX, жмёшь кнопочку upload file и просто ждёшь, когда закончит закачивание... да и все эти upload-серверы типа rapidshare.de, тоже как-то работают (хотя они как раз могут использовать perl)...
Думаю что просто их серваки настроены на разрешение приёма таких больших запросов ))
Я у нашего хостера спрашивал, можно-ли этот параметр увеличить, они сказали что хоть пол гига мне поставят но толку от этого не будет. Залить такой файл по POST без единой ошибки практически нереально. Сейчас стоит 32 метра а всё крупное файло лью по ftp. Для основных клиентов сделал ftp аккаунты и установил Java-ftp клиента прям на сайт.
[b]"но толку от этого не будет"[/b]
ну заливают ведь... и полгига и больше... всё это зависит от качества связи, тем более на некоторых таких сервисах поддерживается докачка даже...
Согласен, но мы пока до этого "немножечко" не доросли... к сожалению
Мне моих 32 метров вполне хватает а для больших объёмов - FTP
все понятно, за исключением в кком файле сделать изменения
upload_max_filesize = ..M
Drupal 5.1
Stanislav php.ini
а где он должен находиться? не нашел!!! можно путь к нему?
Stanislav, какая у тебя OS?
php.ini это файл настроек php, если на локалке, на пример у меня, он лежит в корне папки windows (на сервере в /etc/php4/apache2/php.ini), на рабочем сервере, смотря что тебе позволяет делать хостер.
Что-то я не то сделал похоже, думал в форуме отвечу
Попробовал увеличить upload_max_filesize до 16M через .htaccess и через sites/default/settings.php. (FreeBSD 6.2, Apache 1.3, php 4, drupal 5)
phpinfo говорит, что переменная изменилась, однако файлы больше 2 МБ по-прежнему не заливаются.
Куда смотреть?
Практика показала, что надо менять значения обеих переменных: и upload_max_filesize, и post_max_size.
http://wiki.dreamhost.com/Advanced_PHP_configuration
или друпал-стайл
http://drupal.org/node/113220