The first time you know of a problem is when your image refuses to upload no matter how many times you throw it at the WordPress Media Library. You don’t see any warning message so there you are trawling the internet for days with search variations on ‘Why won’t my image upload in wordpress?’
There’s so much advice out there for dealing with this issue that after a while you realise you’re just reading the same words over and over, it’s all the same but all over the place. The fix is really very simple but there are several ways of approaching it.
There are only two main sources that can provide a solution to this issue, the PHP documentation and the WordPress documentation. The methods below explain how to ensure the correct settings are used.
This post aims to be comprehensive but if you just need the solution then scroll down to the section titled php.ini.
Getting Information about the WordPress installation
So let’s start by verifying the existing upload_max_filesize value. Go to Media Library and click on ‘Add New’, This will expand an upload window and you will see the current value.
This information is also given by PHP on the server. Log In to cPanel and look for the ‘software’ section and open the php module.
Below: Note the directive upload_max_filesize, it confirms the same 2M value that you saw in the Media Library. This value is set by default when the hosting provider sets up your package. Thankfully it can be overridden with code in the WordPress system files.
If WordPress is installed in Multi-site mode then assuming you have Network Admin privileges, the file size limit can be adjusted under
Likewise some WordPress Hosting providers like Cloudways have a built-in feature to change the file size limit and you can change it directly through the options in the platform panel.
Note that multi-site jargon likes to talk in Kilobytes whereas when working with single instance WordPress installs, the figure is in megabytes refered to with the capital letter M, and not m or Mb.
Creating a PHP Info File produces the most information
If you want to get the complete information available from PHP about your install and another way to verify the file upload size limit, then create a file containing PHP code to query the server.
Creating an info.php file will provide all the details on how PHP is configured on your server. It’s frequently used to determine the PHP version number.
PHP, like other languages such as HTML and CSS, is text based, i.e. written in ascii code. Therefore to create a file you do it in an ascii editor such as Notepad. MS Word also allows you to save files in ascii format giving them the extension (.txt).
PHP has a very simple function to call up and display the environment details. In your editor place the following text and save the file giving it the name info.php or phpinfo.php etc, the actual naming part is not important and you can call it what you like.
<?php phpinfo(); ?>
Place the file in the root of the WordPress install. That’s it you’re done.
To use it, put the path in your browser like you would to call any other file. So for this website the correct address would be http://www.webpapa.co.uk/info.php. If you are using WAMP on a localhost then place the file at the root of that install. In this example this would be c:/wamp64/www/webpapa/ and then call it in your browser substituting the word ‘localhost’ for the path, like this:
Finally, remember that this file can provide a lot of useful info to others about your site details so when you’re done, remove the file. If you need it in the future then simply create a new one, after all it’s just one line of code.
Let’s start from the beginning
There are several methods found across the internet that modify the WordPress system files to achieve a higher value for upload_max_filesize, all of them use the same code they just place it in a different file.
This comes down to the PHP and WordPress environment and the configuration of the server. Unless the install is part of a Multi-site then it’s just a matter of figuring out which file to put the code in right. Well not really, this is where the confusion arises.
There was a time when a php.ini file was kept at the root for that server, and the hosting provider would or would not provide user access. This is where workarounds evolved, for example if there is no php.ini then go to .htaccess and try that. However things have changed and now you could have a php.ini file in every directory/folder of your WordPress install if you wanted.
So the nett result is that the php.ini solution is the preferred way to amend file and timing limits. The reason a lot of discussion remains about this, is because the important thing is to always place php.ini in the wp-admin directory, and not the root.
From here, we will now look at the wealth of advice given on this very important topic.
According to some sources adding the following code does the job:
Place this in wp-config.php …
and place this in functions.php …
@ini_set(‘upload_max_size’ , ’64M’);
@ini_set(‘post_max_size’ , ’64M’);
@ini_set(‘max_execution_time’ , ‘300’);
This method has never worked for me and and I fail to see how it could considering these are WordPress specific files that should not override server PHP limits.
So moving quickly on from wp-config.php, let’s look at the code itself because again, there are so many different settings and values recommended out there. All the code we need is in three directives that deal with size limits and not timing limits such as max_execution_time.
post_max_size – The maximum size for posts. Should be higher than upload_max_filesize.
upload_max_filesize – The maximum size for uploads.
The third directive differs widely depending on whose method you are following. Either it is the max_execution_time as this is generally set very low at default (30). Or it is memory_limit which should be set higher than the post_max_size.
Confusion arises about the third directive because both max_execution_time and memory_limit are mentioned in the PHP documentation that discusses resource limits, but here we see that memory_limit is the correct directive to use.
The ‘limit’ sizes vary considerably. Essentially you are free to set whatever limits you want. If you upload videos you might want to set this to 500M or higher. For normal WordPress 128M may suffice, and if uploading audio perhaps 248M would be advisable.
Irrespective of the value we set, we do have a structure to be mindful of as mentioned earlier, regarding the priority of limit sizes, as shown here:
memory_limit – Needs to be higher than post_max_size.
post_max_size – Needs to be equal to upload_max_filesize and higher to work with large files.
upload_max_filesize – The maximum size for uploads.
Bear in mind that memory_limit is usually set just a few megabytes above the post_max_size due to the formula given above. If you upload several audio files successfully and then all of a sudden you run into problems, it’s likely to be just the memory value that needs a higher value.
Consider this example: The initial settings for the webpapa website were upload values of 64M with memory set to 70M as shown above. Normal files were working okay but when I tried uploading a theme configuration file that was no more than 1,400 Kb, the upload failed.
In this instance I had to raise the memory limit way above the other two directives, in fact I doubled the memory value to 128M and things have worked fine since. So my new directives and values are as follows:
memory_limit = 128M
post_max_size = 64M
upload_max_filesize = 64M
On a localhost, if you need to experiment and raise the memory_limit value, it can be done from the WAMP panel by selecting
To change the upload file size limit we first place the following code into php.ini, creating this file if it doesn’t already exist. Then place it in
memory_limit = 128M
post_max_size = 64M
upload_max_filesize = 64M
The php.ini file contains PHP server configuration settings. It will alter the values you see in the PHP info page that we discussed earlier (info.php). If it’s present then it will be found in the WordPress root, so if you don’t see it then you need to create it as stated above. However, an important reminder not to place it in the root but in
It’s not always called php.ini, depending on the type of hosting account, and nor is it absolutely necessary for shared hosting.
For example, with godaddy.com the following initialisation file names apply to the corresponding account types:
- standard cPanel account on /public_html: php.ini
- other web hosting: php5.ini
- managed WordPress: .user.ini
Once you have your php.ini in the wp-admin directory, go to the Media Library and refresh the page. The new value should be displayed – Job done.
If you are running a localhost and perhaps you have several WordPress installs under the /www directory, then these settings can be adjusted in the php.ini file that is at the following path:
If it didn’t work it may be because the version of PHP on your server is not updated. You can update it in cPanel, look in the software section and click on ‘Select PHP Version’.
If you cannot get php.ini to work, put the directives in a file called user.ini and place this in the WordPress root. This method generally works well.
Because many people don’t know to place the php.ini file inside wp-admin, that method fails for them and they move on to .htaccess (a hidden system file situated in the root).
The .htaccess method was a fallback because sometimes the restrictions of servers do not permit use of php.ini files. However, the latest PHP modules grant multiple directory level initialisation files, and so there is no reason why a php.ini file should not work and therefore no reason to use .htaccess.
Are you getting 500 errors using .htaccess?
If your server uses Apache with PHP as an Apache module then you can place file values in .htaccess – right?
Well not exactly. Since PHP 5.3.0, PHP includes support for initialisation files on a per-directory basis. These files are processed only by the CGI/FastCGI SAPI and basically, if you put php directives in .htaccess on an Apache CGI/FastCGI server, it will return a 500 error.
So to recap, the latest PHP version has in effect ruled out using .htaccess for the purpose of increasing the upload file size. In cPanel you can check the ‘software’ section to see the PHP module. You can also check whether CGI/FastCGI is present, see this line below:
So this will confirm that .htaccess is out of bounds for you and why you have received the 500 error if you’ve tried it.
Let’s look a little deeper at FastCGI. There are multiple ways to execute PHP scripts on a web server. The two most common are:
- Apache module
The Apache Module is the most common. It embeds the PHP interpreter with each process on the server meaning that Apache can handle everything that contains PHP code, so it is ideal for PHP intensive requesting environments such as WordPress. The downside is that even when the server is dealing with items that require no PHP such as images and stylesheets, the interpreter is still embedded.
FastCGI executes scripts by an interpreter outside of the web server. PHP scripts are passed to FastCGI which stands between PHP and the web server (Apache). The downside is that any PHP directives defined in an .htaccess file are ignored and will have to be placed in a php.ini file.
So there you have it – Not only can you use php.ini for your directives but the PHP interpreter will not even look at .htaccess.
We have seen that modern versions of PHP no longer look at .htaccess so you should use php.ini to take your PHP directives. But in case you are confronted with older versions here’s how to look at .htaccess.
The cPanel default hides certain system files so to edit .htaccess you must use the Settings to unhide them.
This file configures the Apache server and resides in the WordPress root. It has a dot in front of it, but it’s nothing more than an ascii file and edited in the same way. It’s not a forgiving file, so make sure you are in a position to recover from a white screen of death.
All you need in .htaccess is the filesize directive but it needs some PHP modification, so place the following line at the bottom of the file:
php_value upload_max_filesize 64M
phpMyAdmin and MySQL
Another issue that also brings into play the three directives discussed in this post is when importing a large .sql database file. The upload file size is usually set to 128MiB and the widespread advice on this issue is much the same as for increasing the upload file size in WordPress.
The location of php.ini is in the Apache directory, which you will find in your localhost server under:
Just like the advice for the max upload file size, trying to manually change the upload max file size for phpMyAdmin rarely works even on a localhost. You can spend all day changing values and yet your obese file refuses to upload. I have found the answer is to split the large file into manageable parts as demostrated in the post below.