Расширение php остановило загрузку файла как исправить
Обновлено: 06.07.2024
Ранее у меня был установлен php 5.3.x, но я решил обновить его. Сначала я удалил php 5.3.x, а затем установил php 5.5.1, но после завершения установки apache не проанализировал файлы php, которые он только что загрузил. Я проверял похожие вопросы здесь, в stackoverflow, но пока ни один из них мне не помог.
Буду очень признателен за любую помощь. Спасибо.
У меня есть эти строки в php.conf
apache больше не скачивает файл. Теперь apache показывает исходный код, но не всю его часть. я добавил
Я редактировал вопросы. Модули выходят, и они явно загружаютсяТакже убедитесь, что ваш модуль php загружен
Когда вы настраиваете апач попытайтесь просмотреть страницу из другого браузера - У меня были дни, когда хром упорно кэширует результат и сохраняет загрузку исходного кода в то время как в другом браузере, это просто прекрасно.
Не могли бы вы добавить информацию, куда поместить эти строки? В моем случае на Apache-2.4.6 + PHP-7.3.13> LoadModule php7_module modules / libphp7.soСегодня я столкнулся с этой проблемой, и ни одно из описанных решений не помогло мне. Итак, вот еще одна возможная причина:
Если у вас есть что-то вроде
в .htaccess файле папки веб-содержимого это может привести к тому, что ваши сценарии PHP перестанут работать. В моем случае сервер не знал x-mapp-php6 тип, поскольку этот .htaccess файл был импортирован с другого веб-хоста при переносе содержимого веб-сайта.
Просто удаление AddHandler строки из .htaccess файла решило это для меня.
У меня была некоторая проблема, но я обнаружил виновный файл .htaccess в домашнем каталоге (один каталог над веб-каталогом «public_html»). Если у кого-то еще есть такая же проблема, поищите .htaccess и в родительских каталогах (каскад настроек). У меня был файл .htaccess, подобный этому, который я вытащил с сервера веб-хостинга. Это заставляло версию PHP, которая не была установлена на моем локальном компьютере. Таким образом, виртуальный хост неправильно выполнял файл PHP. Это почти наверняка проблема, если одни сайты работают, а другие - нет. Joomla .htaccess содержал AddHandler, а WordPress - нет. Это сработало для меня, просто удалил эту строку из моего файла public / .htaccess, и индекс был загружен.После долгих усилий я наконец решил проблему.
Если вам будет предложено загрузить .php файл вместо его выполнения, то вот идеальное решение: я предполагаю, что вы уже установили PHP5 и по-прежнему получаете эту ошибку.
затем сделайте следующее:
Оказывается, файлы не должны храниться mods-enabled , а должны храниться в mods-available . Затем в моделях с включенными модами должна быть создана символическая ссылка, указывающая на файл, хранящийся в доступных модах.
Сначала удалите оригинал:
Затем создайте символическую ссылку:
Надеюсь, твоя проблема решена.
Обратите внимание, что это работает только под Linux (и особенно под Debian Linux).Взгляните на свои директивы addtype.
Мне кажется, что Apache сообщает браузеру, что он отправляет тип документа application / php для сценариев с расширениями, такими как .php5. Фактически, Apache должен сообщить браузеру, что сценарий выводит текст / html.
Пожалуйста, попробуйте это:
Что касается приведенного выше предложения о том, что вы должны сообщить браузеру, что вы выводите PHP-скрипт: мне это показалось необычной идеей. Я погуглил и обнаружил, что в сети довольно много дискуссий по этому поводу. По-видимому, есть случаи, когда вы можете сказать, что отправляете PHP-скрипт (даже если Apache должен выполнять скрипт и выдавать текст / html), а также есть случаи, когда браузер просто не распознает этот конкретный Mime Тип.
Очистка кеша браузера - всегда хорошая идея.
Это интересно, но в моем случае он просто выводит весь скрипт PHP, на этот раз в формате HTML (а не только в формате ASCII) - бесполезно! Проблема здесь в том, что PHP каким-то образом не запускается правильно или отправляются неправильные заголовки . Обратите внимание, что последняя директива AddType (закомментированная в приведенном выше примере) заставляет файл .phps хорошо печататься в HTML. Возможно ли, что ваша конфигурация Apache хорошо печатает файлы .php?Это могло произойти из-за отсутствия модулей, необходимых для вашего php. Предполагая, что у вас установлен php7, выполните поиск доступных модулей php7, используя
Вышеупомянутая команда перечислит все доступные модули PHP7 для установки. Вы можете начать установку таких модулей, как,
У меня такая же проблема. Apache не загружает файлы php с определенного веб-сайта, а просто загружает их. Я прочитал этот пост и ответы, и я увидел, что эта строка находится на последнем месте файла .htaccess:
Я прокомментировал это, и все работает нормально.
У меня раньше была аналогичная проблема после обновления с 5.3 до 5.4. Но моя установка выглядит немного иначе, поскольку я запускаю Debian и использую fcgid для сервера страниц PHP, а не модуль PHP5 apache / cgi. Поэтому после того, как я обновился, он также установил php5_cgi, который столкнулся с моей настройкой fcgid и больше не выполнял файлы PHP.
Мне пришлось отключить модуль Apache и перезапустить Apache
Как только модуль php5_cgi был отключен, fcgid снова смог обслуживать страницы PHP.
Ах да, этот хитрый ублюдок cgi ^^ Моя проблема была решена после обновления php с 5.3 до 5.4 с dotdeb.У меня были похожие симптомы, еще одно решение: в /etc/apache2/mods-enabled/php5.conf в комментарии был полезный совет, которому я следовал:
Если кто-то использует php7 в среде Linux
Убедитесь, что вы включили php7
Перезапустите службу mysql и Apache
После обновления PHP до версии 7.3 скрипты PHP запускаются с www-данными вместо $ USER, как раньше.
Мне нужно было переустановить и активировать PHP-FPM:
Чтобы убедиться, что с Virtualmin все в порядке , я использовал мастер повторной проверки конфигурации в /virtual-server/check.cgi разделе Vitualmin / System Settings .
После перезапуска Apache моя проблема была решена, надеюсь, это поможет.
Позаботьтесь и о кеше браузера.
Я потратил два дня, отслеживая это, и обнаружил, что помещаю свои PHP-скрипты не в тот каталог.
В моей стандартной установке Ubuntu я помещал скрипты в /var/www . Они должны были быть внутри /var/www/html .
Я только начал работу с PHP, поэтому не знаю, связано ли мое решение с изменением версии, через которое вы прошли.
это решило проблему для меня (у меня установлен php7):
sudo apt-get установить libapache2-mod-php7.0
sudo service apache2 перезапуск
Также возможно, что у вас запущен nginx, но ваш php настроен для работы с apache. Чтобы проверить, запустите service nginx status и service apache2 status посмотрите, какой из них работает. В случае, если nginx запущен, а apache нет, просто запустите, sudo service nginx stop; sudo service apache2 start и ваш сервер теперь будет обслуживать файлы php, как ожидалось.
Вывод
Если бы я закомментировал эти две строки в своих .conf-файлах в /etc/apache2/[[SERVER-NAME].conf -file:
Я понятия не имею, что они делают и как они туда попали, но это есть в каждом из моих .conf файлов. И если я удалю эти строки и обеспечу наличие символической ссылки в /etc/apache2/sites-enabled/ папке , тогда он не загрузит index.php - и все будет работать так, как должно.
Вся история
Я перепробовал все:
- Удален PHP7.2 и установлен PHP5.6 (теперь я знаю, что версия PHP не имеет к этому никакого отношения; нужно доработать конфигурацию apache).
- Пробовал включать и отключать модули apache в существующей установке, но безуспешно.
- Затем я полностью удалил apache и снова установил его, после чего проблема все еще оставалась существовала!
- Пытался поиграть с настройкой Virutal Server в VirtualMin (Webmin >> Servers >> Apache Webserver).
- Проверил конфигурацию на одном виртуальном сервере (Virtualmin >> System Settings >> Re-Check Configuration) . Этот шаг был довольно приятным, так как он сказал, какой модуль в Apache отсутствует; где-после я мог бы включить его с помощью a2enmod [MODULE_NAME] . И я нашел имя модуля в Google. Мне пришлось активировать около 6-8 модулей, прежде чем я прошел этот этап проверки - а потребовалось несколько минут до того, как закончился кеш, - так что это было утомительным шагом.
- И, наконец, я придумал вышеизложенный вывод - вместе с символическими ссылками - и затем заставил его работать. Однако мне пришлось пройти через это для каждого сайта на моем VPS.
У меня была эта проблема, и если вы на самом деле никогда не играли с настройками конфигурации вашего сервера, то ваша проблема на 90% в вашем файле .htaccess
Вы либо изменяете файл .htaccess ЛОКАЛЬНО, либо удаляете его (ЛОКАЛЬНО)
У меня была проблема, аналогичная OP, при обновлении php5 со старой версии до 5.5.9, которая является версией, установленной с Mint 17.
Я запускаю установку LAMP на машине в моей локальной сети, которую я использую для предварительного просмотра изменений на веб-сайтах, прежде чем загружать эти изменения на реальный действующий сервер. Так что я поддерживаю идеальное локальное зеркало фактического сайта.
После обновления файлы, которые отлично работают и отображаются на реальном сайте, не будут отображаться или будут отображать только html на локальном компьютере. PHP не разбирался. Команда phpinfo () работала, поэтому я знал, что в остальном php работает. Журнал не выдал ошибок. Просмотр исходного кода страницы показал мне актуальный php-код.
Я создал страницу test.php, содержащую следующий код:
Это сработало. Потом я обнаружил , когда я изменил <?php в <? команде больше не работал. Все мои сайты php используют <? вместо этого, <?php возможно, это не идеально, но это реальность. Я исправил проблему, перейдя в / etc / php5 / apache2, выполнив поиск «short_open_tag» и изменив значение с Off на On.
Мой / etc / nginx / sites-available / default
Прочие «локации» прокомментированы .
Изменить /etc/nginx/sites-available/default
Раскомментируйте обе строки прослушивания, чтобы nginx прослушивал порт 80 IPv4 и IPv6.
Оставьте server_name в покое
Добавьте index.php в строку index
Раскомментировать location
Отредактируйте /etc/php5/fpm/php.ini и убедитесь, что для cgi.fix_pathinfo установлено значение 0
Перезапустите nginx и php5-fpm sudo service nginx restart && sudo service php5-fpm restart
Я начал использовать Linux только неделю назад, поэтому очень надеюсь помочь вам в этом. Я использую текстовый редактор nano для редактирования файлов. запустите apt-get install nano, если у вас его нет. Google, чтобы узнать больше.
Я долго боролся с этой проблемой, и эти шаги у меня сработали.
Шаг 1. Конфигурация блока расположения для всех файлов PHP
Шаг 2. Добавьте fastcgi_param в файл конфигурации. Нам просто нужно открыть файл / etc / nginx / fastcgi_params и добавить следующую строку в конец файла.
А затем перезапустите службы,
Вам нужно добавить это в / etc / nginx / sites-enabled / default для выполнения файлов php на сервере Nginx:
У меня была аналогичная проблема, которая была решена путем очистки кеша браузера (также отлично работала с другим браузером).
Обновите конфигурацию nginx / etc / nginx / sites-available / default или свой файл конфигурации
Если вы используете php7, используйте это
Если вы используете php5, используйте это
Посетите здесь, чтобы получить полную информацию. Подробности здесь
Я вижу много решений выше, и многие из них работали у меня правильно, но я не понимал, что они делают, и беспокоился о том, чтобы просто скопировать и вставить код, в частности, fastcgi . Итак, вот мои 2 цента,
- nginx - это веб-сервер (а не сервер приложений ), поэтому он может обслуживать только статические страницы.
- всякий раз, когда мы пытаемся отобразить / вернуть файл .php, например index.php, nginx не знает, что делать, поскольку он просто не может понять файл .php (или, если на то пошло, любое расширение, кроме нескольких избранных, таких как .html, .js и т. д., которые являются статическими файлами)
- Таким образом, для запуска других типов файлов нам нужно что-то, что находится между nginx и приложением (здесь приложение php). Именно здесь на помощь приходит общий интерфейс шлюза (CGI). Это часть программного обеспечения, которое управляет этой связью. CGI могут быть реализованы на любом возможном языке Python (uWSGI), PHP (FPM) и даже C. FastCGI - это, по сути, обновленная версия CGI, которая намного быстрее, чем CGI.
Для некоторых серверов, таких как Apache, встроена поддержка интерпретации PHP, и поэтому нет необходимости в CGI.
Эта цифровая ссылка на океан довольно хорошо объясняет шаги по установке FPM, и я не пишу шаги, необходимые для решения проблемы загрузки файлов php вместо рендеринга, поскольку другие ответы IMHO довольно хороши.
Для тестирования файла конфигурации в / etc / nginx / sites-available / default.
Это дало мне следующие ошибки:
Итак, я зашел в файл конфигурации, и в последней строке было
Я раскомментировал, снова запустил тестовую команду, и она сработала
Это сработало для меня.
1) Файл MyApp
Vi / и т. д. / nginx / сайты-доступные / myApp
2) Настройте cgi.fix_pathinfo
Установите cgi.fix_pathinfo в 0
3) Перезапустите службы
Php5 sudo service php5-fpm restart
Php7 sudo service php7.0-fpm restart
Мне помогло добавить ?$query_string в конец /index.php, как показано ниже:
listen = 127.0.0.1:9000;(delete all line contain listen= )
remove server block server<> (if exist) in block html<> because we use server<> in default (config file in etc/nginx/site-available) which was included in nginx.conf.
4. перезапустить службу nginx
5. перезапустите службу php
6. наслаждаться
Создайте любой файл php в / usr / share / nginx / html и запустите в «имя_сервера / имя_файла.php» (имя_сервера зависит от вашей конфигурации, обычно это localhost, имя_файла.php - имя файла, созданного в / usr / share / nginx / html).
Я использую Ubuntu 14.04
Приведенные выше фрагменты работали для меня в случае php7.2
Приведенный выше ответ, казалось, слишком много комментировал решение, которое я достиг. Вот как выглядел мой файл:
/ и т.д. / nginx / сайты-доступные / по умолчанию
Надеюсь, это поможет некоторым людям, которые расстроены воскресным днем (c:
Мое решение было добавить
Добавление в /etc/nginx/sites-available/default у меня не сработало.
Для тех, у кого такая же проблема с PHP 7, это то, что я сделал, чтобы nginx правильно выполнял файлы php в CentOS 7, размещенный здесь, поэтому на случай, если у кого-то возникнет такая же проблема:
Пошагово следуйте этому документу на Цифровой океан.
Откройте /etc/nginx/conf.d/default.conf (по умолчанию у меня нет сайтов с включенными или доступными сайтами, вы можете отредактировать их соответствующим образом).
Отредактируйте параметр location , как показано ниже:
Перезапустите службы Nginx и PHP sudo systemctl restart php-fpm и sudo systemctl restart nginx .
И последнее, но самое важное: очистить кеш браузера или запустить его в incognito (Chrome) или Private Browsing (Firefox) и т. Д.
Надеюсь, это полезное и счастливое кодирование
Затем перезагрузите Nginx:
Это то, что в конечном итоге сработало в моем случае как правила перезаписи, в которых виноват
Я изменил правила перезаписи nginx следующим образом.
Очевидно, без ключевого слова last запрос не был перезапущен, поэтому он не попал в сегмент местоположения .php и был просто интерпретирован как загрузка -
Теперь я решил свою проблему с помощью этого кода (измените свой IP):
Что сработало для меня с Ubuntu 16.04, а php7 удалял эту строку
После этого он перестал скачивать файлы php.
Раскомментируйте расположение .php в / etc / nginx / sites-available / default
sudo vi / etc / nginx / sites-available / default:
Если что-то еще тебе не поможет. А может быть, раньше вы установили apache2 с тестовым файлом info.php. Просто очистите данные приложения (кеш, cookie) для localhost.
Проверьте, что расширение файла конфигурации nginx - * .conf.
например: /etc/nginx/conf.d/myfoo.conf
У меня такая же ситуация. После того, как я переименовал свой файл конфигурации с myfoo в myfoo.conf, он исправился. Не забудьте перезапустить nginx после его переименования.
Сначала вам нужно Remove cache в браузере
Затем откройте терминал и выполните следующую команду:
Затем добавьте следующий код в файл default :
Если какое-либо несоответствие, просто исправьте и перезапустите Nginx с терминала с помощью следующей команды
sudo systemctl перезапустить nginx
Затем перейдите в браузер и наслаждайтесь .
Для меня это была строка: fastcgi_pass unix: /var/run/php5-fpm.sock;
Что должно было быть просто: fastcgi_pass unix: /run/php5-fpm.sock;
Решением для меня было очистить кеш Cloudflare.
У меня была та же проблема, которая решила, что этот блок сервера также имеет этот блок над другими блоками местоположения, если у вас есть проблемы с загрузкой css. Который я добавил в свой файл conf, доступный для сайтов.
Для записи, я обнаружил, что мой php-fpm не работает, и исправил это с помощью service php7.2-fpm stop
(Я настраивал этот сервер в первую очередь для электронной почты и не использовал PHP, когда впервые установил nginx, просто как способ более легкого запуска certbot.)
В этой статье я расскажу об основах загрузки файлов в PHP. Во-первых, мы рассмотрим параметры конфигурации PHP, которые должны быть установлены для успешной загрузки файлов. После этого мы разработаем реальный пример загрузки файла.
Настройка параметров PHP
Существует несколько настроек конфигурации PHP, которые вам следует предварительно проверить для успешной загрузки файлов. В этом разделе мы рассмотрим все параметры, которые важны для загрузки файлов PHP. Эти параметры можно настроить в файле php.ini.
Если вы не знаете, где найти файл php.ini, вы можете использовать php_ini_loaded_file() , чтобы найти его. Просто создайте файл PHP на своем сервере со следующей строкой и откройте его из браузера.
Вот выдержка из установочного файла с некоторыми полезными значениями по умолчанию.
Ключевые настройки
file_uploads
Значение директивы file_uploads должно быть установлено на On , чтобы разрешить загрузку файлов. Значение по умолчанию для этой директивы - On .
upload_max_filesize
upload_tmp_dir
Устанавливает временный каталог, который будет использоваться для хранения загруженных файлов. В большинстве случаев вам не нужно беспокоиться об этой настройке. Если вы не установите его, будет использоваться системный временный каталог по умолчанию.
post_max_size
Директива post_max_size позволяет настроить максимальный размер данных POST. Поскольку файлы загружаются с помощью POST-запросов, это значение должно быть больше, чем указано в директиве upload_max_filesize . Например, если ваш upload_max_filesize составляет 16M (16 мегабайт), вам может потребоваться установить post_max_size в 20M .
max_file_uploads
Это позволяет вам установить максимальное количество файлов, которые могут быть загружены за раз. По умолчанию 20 , разумное количество.
max_input_time
Это максимальное количество секунд, которое скрипту разрешено анализировать входные данные. Вы должны установить его на разумное значение, если вы имеете дело с большими загрузками файлов. 60 (60 секунд) является хорошим показателем для большинства приложений.
memory_limit
Директива memory_limit указывает максимальный объем памяти, который может потреблять скрипт. Если вы сталкиваетесь с проблемами при загрузке больших файлов, вам необходимо убедиться, что значение этой директивы больше, чем указано в директиве post_max_size . Значение по умолчанию - 128M (128 мегабайт), поэтому, если у вас нет очень больших post_max_size и upload_max_filesize , вам не нужно беспокоиться об этом.
max_execution_time
Это максимальное количество секунд, разрешенное для работы скрипта. Если вы сталкиваетесь с проблемами при загрузке больших файлов, вы можете рассмотреть возможность увеличения этого значения. 30 (30 секунд) должны хорошо работать для большинства приложений.
Теперь давайте построим реальный пример, чтобы продемонстрировать загрузку файлов в PHP.
Создание формы HTML
После того, как вы настроили параметры PHP, вы готовы испытать возможности загрузки файлов PHP.
В нашем репозитории GitHub есть пример кода, который я собираюсь обсудить в этой статье. Итак, если вы хотите следовать ему, загрузите его из GitHub.
Мы собираемся создать два файла PHP: index.php и upload.php. Файл index.php содержит код, который отвечает за отображение формы загрузки файла. С другой стороны, файл upload.php отвечает за загрузку файла на сервер.
Кроме того, файл будет загружен в каталог uploaded_files, поэтому вам нужно убедиться, что эта папка существует и доступна для записи пользователем web-server .
В этом разделе мы рассмотрим ключевые части файла index.php.
Давайте посмотрим на файл index.php на GitHub:
Хотя это может показаться типичной формой PHP, существует важное различие в значении атрибута enctype тега <form> . Он должен быть установлен в multipart/form-data , так как форма содержит поле файла.
Атрибут enctype указывает тип кодировки, который должен использоваться при отправке формы, и он принимает одно из следующих трех значений:
- application/x-www-form-urlencoded : Это значение по умолчанию, когда вы не устанавливаете значение атрибута enctype явно. В этом случае символы кодируются перед отправкой на сервер. Если у вас нет поля файла в вашей форме, вы должны использовать это значение для атрибута enctype .
- multipart/form-data : Когда вы используете значение multipart/form-data для атрибута enctype , оно позволяет загружать файлы с использованием метода POST. Кроме того, он гарантирует, что символы не кодируются при отправке формы.
- text/plain : Обычно это не используется. С помощью этой настройки данные отправляются без кодирования.
Затем мы выводим поле файла, которое позволяет вам выбрать файл с вашего компьютера.
Итак, это был файл index.php. В следующем разделе мы рассмотрим, как обрабатывать загруженный файл на стороне сервера.
Логика загрузки
В предыдущем разделе мы создали форму HTML, которая отображается на стороне клиента и позволяет загружать файл с вашего компьютера. В этом разделе мы увидим серверную часть кода, которая позволяет обрабатывать загруженный файл.
Загрузите код из файла upload.php на GitHub. Мы рассмотрим важные части этого файла.
В файле upload.php мы проверили, действительно ли это валидный запрос POST.
В PHP, когда файл загружается, суперглобальная переменная $_FILES заполняется всей информацией о загруженном файле. Она инициализируется как массив и может содержать следующую информацию для успешной загрузки файла.
После проверки запроса POST мы проверяем, что загрузка файла прошла успешно.
Вы можете видеть, что переменная $_FILES является многомерным массивом, первый элемент - это имя поля файла, а второй элемент содержит информацию о загруженном файле, как мы уже говорили выше.
Если загрузка файла прошла успешно, мы инициализируем несколько переменных с информацией о загруженном файле.
В приведенном выше коде мы также выяснили расширение загруженного файла и сохранили его в переменной $fileExtension .
Поскольку загруженный файл может содержать пробелы и другие специальные символы, лучше очистить имя файла, и это именно то, что мы сделали в следующем шаге.
Важно, чтобы вы ограничивали тип файла, который может быть загружен на определенные расширения, и не разрешали все. Мы это сделали, проверив расширение загруженного файла с помощью набора расширений, который мы хотим разрешить для загрузки.
Наконец, мы используем функцию move_uploaded_file для перемещения загруженного файла в определенное место по нашему выбору.
Функция move_uploaded_file принимает два аргумента. Первым аргументом является имя файла загруженного файла, а второй аргумент - путь назначения, в который вы хотите переместить файл.
Как это все работает вместе
Не забудьте создать каталог uploaded_files и сделать его доступным для записи пользователем web-server. Затем перейдите и запустите файл index.php, который должен отобразить форму загрузки файла, которая выглядит так:
Заключение
Сегодня мы обсудили основы загрузки файлов на PHP. В первой половине статьи мы рассмотрели различные параметры конфигурации, которые должны быть установлены для загрузки файлов на работу. Затем мы рассмотрели реальный пример, который продемонстрировал, как загрузка файлов работает на PHP.
Надеюсь, вам понравилась эта статья, и вы можете свободно размещать свои вопросы и предложения ниже!
Какой загруженный файл превышает директиву upload_max_filesize в ошибке php.ini?
Хостинг-провайдеры ограничивают размер загружаемого файла для защиты сервера. Код Upload_max_filesize можно найти в вашем файле php.ini. Файл php.ini – это структура PHP по умолчанию на вашем сервере.
Эти ограничения в основном устанавливаются хостинг-провайдером, и вы можете увидеть их, перейдя в панель управления WordPress, Медиа и нажав Добавить.
1. Увеличьте upload_max_filesize в WordPress
С помощью FTP-клиента подключитесь к корневому каталогу вашего сервера и вставьте приведенный ниже код в конец файла wp-config.php:
Теперь вы изменили ограничение на размер загрузки до 256 мегабайт.
2. Увеличьте upload_max_filesize в cPanel
Если ваш хост использует cPanel, войдя в свою cPanel, вы можете просто внести изменения в php.ini.
Сначала найдите MultiPHP INI Editor. Затем выберите свой сайт на открывшейся странице. Вы можете увидеть несколько настроек, которые можно редактировать. Прокрутите вниз до upload_max_filesize и измените его значение на желаемое.
3. Увеличьте upload_max_filesize с помощью FTP.
Как упоминалось выше, php.ini управляет структурой PHP вашего сервера. Если ваш хостинг-провайдер разрешает вам доступ к файлу php.ini, вы можете внести в него необходимые изменения.
С помощью FTP-клиента подключитесь к своему серверу и перейдите в свой каталог. Если вы не можете найти php.ini (или php5.ini) для его редактирования, вы можете просто создать файл с тем же именем и добавить в него код, указанный ниже.
Если вы используете XAMPP, Wamp или MAMP, вы можете найти php.ini в:
Имейте в виду, что некоторым хостинг-провайдерам требуется suPHP в файле .htaccess для запуска упомянутого кода. Убедитесь, что вы добавили приведенный ниже код в свой файл .htaccess:
Убедитесь, что вы изменили имя пользователя на свой фактический путь.
Вышеупомянутые конфигурации могут отличаться для разных хостинг-провайдеров. Поэтому, чтобы убедиться, что они действительно подходят для вашего сервера, вы можете просто связаться с вашим хостинг-провайдером или просмотреть их форумы.
4. Увеличьте upload_max_filesize с помощью файла .htaccess.
Если ваш хостинг-провайдер не позволяет вам редактировать или создавать файл php.ini, вы можете внести некоторые изменения в файл .htaccess, чтобы изменить upload_max_filesize. Для этого подключитесь к серверу с помощью FTP-клиента и откройте свой основной каталог. Найдите файл .htaccess и добавьте следующие коды:
5. Увеличьте upload_max_filesize в файле function.php.
Вы можете изменить числа, указанные выше, на те ограничения, которые вам подходят.
Вывод
Если ни один из вышеперечисленных методов не помог вам, вам необходимо связаться со службой поддержки вашего хостинг-провайдера и сообщить им о ситуации.
Чтобы убедиться, что описанные выше методы сработали, вы можете перейти на панель управления WordPress, медиа и нажать «Добавить новый» и найти ограничение на размер загрузки. Если лимит изменился с прежнего на число, которое вы ввели в свои коды, значит, оно сработало. Если нет, то вам необходимо связаться с вашим хостинг-провайдером.
Имейте в виду, что если у вас по-прежнему возникают проблемы с загрузкой файла на веб-сайт, вы можете использовать FTP-клиент для загрузки файлов на сервер. Потому что FTP не имеет ограничений на размер загрузки.
Читайте также: