Preface

Friends who use WordPress to build websites, if there are the following application scenarios: installing new themes, installing plug-ins, uploading files and pictures, etc., most of them probably have encountered the embarrassing problems shown in the figure below:

This is because WordPress is developed using the PHP language, and php.ini is the main configuration file for PHP, which defines PHP's global settings, including upload_max_filesize, post_max_size and other parameters. These settings apply by default to all PHP scripts running on the server (WordPress is no exception). Because the default values of some parameters are set too conservatively, such as the default value of "upload_max_filesize" is 2M, the error shown in the figure above will appear when WordPress uploads files larger than 2M.

This article lists several solutions to this problem. You can choose the solution that best suits your situation based on your actual environment.

Solution Summary

Modify php.ini (generally not recommended)

This method has the greatest impact (it will affect all PHP scripts on the entire host, so use with caution). It is not recommended under normal circumstances (whether it is source code deployment or Docker deployment of WordPress, it is not recommended). However, if you have to choose one of the two, it is more convenient to use this method when deploying WordPress from source code. Of course, you also need administrator privileges on the deployment host.

1. Find the php.ini file :
   On your server, find php.ini The location of the file. This file is usually located in the directory where your PHP is installed, or in your hosting control panel.
2. Edit php.ini file :

upload_max_filesize = 100M # defaults to 2M, which is the culprit for not being able to upload large files. Change it to the value you need, such as 100M post_max_size = 64M # defaults to 8M, this parameter affects the size of the uploaded article, generally 8M is enough, you can change it to a larger value, such as 64M

3. Restart the server :
   After modification, save the file and restart your web server (such as Apache or Nginx) for the changes to take effect.

Modify the .htaccess file (recommended for docker deployment and Apache source code deployment)

Note:.htaccess The file is used to configure the behavior of the Apache web server. Its name is an abbreviation for "hypertext access" and is usually located in the root directory or a subdirectory of the website. The scope of the file is the directory in which it is located and its subdirectories. Each directory can have its own .htaccess file, and can override the settings of the parent directory. .htaccess File, web administrators can have fine-grained control over the server's configuration without having to modify Apache's main configuration file directly.

Since modifying php.ini has a huge impact and requires high permissions, it is not suitable in many cases. In fact, this method is more suitable for the scenario of deploying WordPress from source code. At present, most friends like to use docker to deploy. If this method is used, it is necessary to enter docker to modify php.ini, which is very inconvenient.

At this time, modifying the ".htaccess" file is a less impactful option (generally servers allow .htaccess files to overwrite PHP settings), applicable scenarios:
1. WordPress deployed in docker mode (because the image created by docker uses Apache as the web server)
2. Friends who use Apache as the web server source code to deploy WordPress and have WordPress site directory management permissions

In the wordpress root directory (if deployed in docker, use the -v parameter on the host to mount it to the "wordpress/html/" directory of the container) .htaccess Add the following lines to the file (hidden file):

php_value upload_max_filesize 100M php_value post_max_size 64M

As shown below:

Later, when the Apache server reads the .htaccess file, it applies these configurations, overwriting the default values in php.ini.

Note: For the scenario of deploying WordPress from source code, modifying .htaccess is only suitable when the web server is Apache. If the web server is Nginx, this method is not suitable. Instead, you need to modify the php.ini and nginx configuration files at the same time: In addition to modifying php.ini as mentioned above, you also need to add or modify the following lines in the server block (server {}) or location block (location {}) in the nginx configuration file:

client_max_body_size 64M;

Then save the file and restart nginx to take effect.

Modify the functions.php of the wordpress theme or use a dedicated plugin

In addition to the above two methods, you can also try to solve the upload problem by modifying the functions.php file of the WordPress theme or using a dedicated plug-in.

Modify the theme's functions.php

The functions.php file is in the directory of the theme being used, the path is "/wordpress/html/wp-content/themes/xxxxx",
Add the following content:

@ini_set( 'upload_max_size' , '64M' ); @ini_set( 'post_max_size', '64M'); @ini_set( 'max_execution_time', '300' );

Note: This approach may not always work, as modifying the PHP configuration via ini_set() in functions.php may not always work, especially if you encounter configuration limits on your web server or constraints in your hosting environment. To ensure that the upload limit is modified correctly, you will usually need to edit the php.ini file directly, the web server configuration file, and if using Docker, ensure that the Docker container configuration correctly reflects these changes, so if it doesn't work, that's OK.

Dedicated plugins

Some dedicated plugins, such as "Increase Maximum Upload File Size" and "WP Upload Size", provide the function of directly modifying the upload file size limit. Unfortunately, this method is the same as modifying the theme's functions.php file, and may not necessarily take effect (because it is essentially a php.ini limitation).

The ultimate method: bypassing the PHP level and uploading directly

If the previous methods are still within the rules and focus on breaking the default upload limit of PHP in a reasonable and legal way, the remaining method directly skips the PHP level and faces the essence of the problem. So what is the essence of uploading and installing the theme in the WordPress management backend?

Essentially, installing a theme in WordPress is just uploading the theme’s zip package to the “wordpress/html/wp-content/themes/” path and then unzipping it. If you are installing a plug-in, you are uploading the plug-in’s zip package to the “wordpress/html/wp-content/plugins/” path and then unzipping it. If you are uploading an image, you are uploading the image directly to the “wordpress/html/wp-content/uploads/xxxx/xx/” path.

So, since the essence is like this, why not just use various methods (ftp, sftp, various file upload functions that come with Linux panels, etc.) to upload the zip package to the corresponding location, and then decompress it? What else do you need?

However, the reason why I put this method at the end is that I think it is a bit not very decent: there is no feeling of fighting back and forth (just like Tang Bohu and Dui Chuanchang), it is more like cheating and turning the table over. Moreover, this method is not suitable for some WordPress deployment methods: such as WordPress deployed by virtual host.

However, generally speaking, this should be the most effective method besides modifying ".htaccess", so after careful consideration, we decided to add this solution. You can use it as appropriate.

Summarize

At present, for wordpress deployed in docker mode, the most convenient way to break the upload file size limit is to modify the ".htaccess" file in the root directory of the mounted folder (the general path is "wordpress/html/" of the host machine) (I have always been disgusted with the behavior of directly modifying files inside docker). Of course, it is also suitable for the scenario of deploying wordpress using Apache source code.

Apart from that, there is the direct upload method. There is nothing much to say about this. As long as you have the corresponding permissions to deploy the WordPress host, you can use it.

As for the method of directly modifying php.ini, it depends on your actual environment. If you use source code deployment, and you are the administrator of the host, and you think the impact does not matter, then this is also a simple way.

As for those who are not convenient or do not want to modify ".htaccess" and "php.ini" right away, modifying the theme's functions.php and using dedicated plug-ins are at least methods that can be tried first: if it succeeds, that's the best, but if it doesn't, there are still options available as a backup.