I am a freelance WordPress developer in Surat, and I fix this on new client sites almost every month. Most of the time fixing the WordPress upload limit takes a few minutes once you know which setting your server actually reads.

Where the WordPress upload limit comes from

WordPress itself does not decide how big a file can be. The WordPress upload limit comes from PHP and the web server. Three PHP settings matter most:

• upload_max_filesize: the largest single file PHP will accept.
• post_max_size: the largest whole request, which includes the file plus form data. It must be equal to or bigger than upload_max_filesize.
• memory_limit: how much memory PHP can use. WordPress needs extra memory to process images after upload, so this should be higher than the other two.

On top of PHP, the web server can have its own cap. Nginx uses client_max_body_size, and when a file is too big for it you see a “413 Request Entity Too Large” page instead of a WordPress message. The PHP settings are described in the official PHP core settings documentation.

How I check the current WordPress upload limit

Before changing anything, I look at what the site is using right now. There are two quick places in wp-admin:

• Media > Add New: the line under the upload box says “Maximum upload file size” with the current value.
• Tools > Site Health > Info: the Media Handling section shows the max size of an uploaded file, and the Server section shows the upload and post size values PHP reports.

The Site Health screen is the one I trust most, because it shows what PHP really loaded, not what a config file claims. I note the current numbers so I can confirm later that my change worked.

Pick a sensible size first

It is tempting to set everything to 1 GB and forget about it. I do not do that. A huge WordPress upload limit lets anyone with an account push very large files to the server, which fills disk space and makes backups slower.

For most business sites, 64 MB is plenty. It covers large PDFs, theme and plugin zips, and short videos. For a site that really needs bigger files, I go to 128 MB or 256 MB. Long videos are better on YouTube or Vimeo and embedded, rather than stored in the media library.

5 ways I raise the WordPress upload limit

Which method works depends on how your host runs PHP. I try them in this order, from the cleanest to the last resort.

1. The hosting control panel

Most hosts now let you change PHP settings from their dashboard. In cPanel this is usually under Select PHP Version (Options tab) or the MultiPHP INI Editor. Other hosts have a “PHP settings” page per site. I set upload_max_filesize and post_max_size to the same value, raise memory_limit if needed, and save. This is the safest way to change the WordPress upload limit because the host writes the setting in the right place for its own setup.

2. A php.ini or .user.ini file

If there is no panel option, I add a small ini file in the site root, the same folder as wp-config.php. On many shared hosts that run PHP as FastCGI or PHP-FPM, the file is called .user.ini. On some older setups it is php.ini. The content is the same:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

One thing that catches people: PHP caches .user.ini for a few minutes, so the new value may not show straight away. I wait five minutes and check Site Health again before deciding it did not work.

3. The .htaccess file (Apache with mod_php only)

On Apache servers that run PHP as a module, you can set the values in .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

Be careful here. On servers that do not run mod_php, these lines cause a 500 Internal Server Error and the whole site goes down. I always keep a copy of the original file and test the homepage right after saving. If you see a 500 error, remove the lines and use the ini file method instead.

4. Ask the host to raise the server cap

If PHP shows the new value but large uploads still fail with a 413 error, the limit is at the web server level. On Nginx that is client_max_body_size, which only the host or server admin can change. On a VPS I edit it myself and reload Nginx, as covered in the WordPress Nginx guide. On shared hosting I open a support ticket and give the exact value I want.

5. Multisite network settings

On a WordPress Multisite network there is one more cap. Under Network Admin > Settings, the “Max upload file size” field is set in KB and applies to every site in the network. Even with PHP set to 64 MB, a low number here becomes the real WordPress upload limit and blocks uploads, so I raise it to match.

What does not work (and why)

Many tutorials suggest adding @ini_set( 'upload_max_filesize', '64M' ); to wp-config.php or the theme’s functions file. On most servers this does nothing to the WordPress upload limit. PHP only reads upload_max_filesize and post_max_size when the request starts, before WordPress loads, so changing them from inside WordPress is too late. If you added these lines and nothing changed, that is why. I remove them to keep the config clean.

The same goes for random upload plugins that promise to raise the limit. They can only change the number WordPress displays or write to the same files I mention above. They cannot override the server.

Check the new WordPress upload limit worked

After any change, I go back to Media > Add New and Site Health and confirm the new value. Then I do a real test: I upload a file slightly smaller than the new limit and make sure it finishes and shows in the media library. For images, I also check that the thumbnails were created, because a low memory_limit can let the upload finish but stop image processing. If that happens, my guide on fixing WordPress memory limit errors covers the next step.

If uploads work but files show broken links or permission errors afterwards, the folder permissions on wp-content/uploads are often the cause. I explain the values I use in my post on WordPress file permissions.

Keep uploads lean anyway

Raising the WordPress upload limit fixes the error, but large files still slow a site down. I resize and compress images before uploading, keep PDFs reasonably sized, and embed videos instead of hosting them. WordPress also scales down very large images automatically, but starting with a sensible size saves disk space and backup time.

If your uploads keep failing and you are not sure which setting your server reads, I can check it and set the right limit for you. Get in touch and tell me which file you are trying to upload and what error you see.

The post How I Increase the WordPress Upload Limit (and Fix File Size Errors) appeared first on Nitin Rathod.

I am a freelance WordPress developer in Surat, and I do a WordPress PHP update for sites of all sizes, from simple blogs to busy WooCommerce stores. The steps are the same every time.

Why a WordPress PHP update matters

PHP is the language WordPress runs on. Every page load runs through it, so the version on your server affects speed, security and what your plugins can do.

• Security: old PHP versions stop getting security fixes. Once a version is end of life, any new hole in it stays open.
• Speed: newer PHP versions run the same code faster and use less memory. On most sites I see a clear drop in server response time after the switch.
• Compatibility: plugin and theme developers drop support for old versions. If you stay behind, you eventually cannot install updates at all.
• Hosting: hosts retire old versions and move sites up automatically. That forced move is when most breakages happen, because nobody tested first.

WordPress publishes its recommended versions on the official WordPress requirements page. I use that as the target, not just “whatever the host offers”.

Step 1: Check what you are running now

Go to Tools > Site Health > Info in wp-admin and open the Server section. It shows the current PHP version, the memory limit and the main extensions. Your hosting panel (cPanel, Plesk or a custom dashboard) will also show the version and usually lets you change it per site.

I write down the current version before touching anything. If something goes wrong, I want to know exactly what to switch back to.

Step 2: Back up and use staging for the WordPress PHP update

Before any WordPress PHP update I take a full backup of files and database, and I make sure I can actually restore it. Then I copy the site to a staging environment where I can test without real visitors or customers seeing errors. I covered that habit in my post on using a staging site before plugin updates, and the same logic applies here.

If your host has no staging option, a local copy works too. The point is to see problems on a copy, not on the live site.

Step 3: Update WordPress, plugins and theme first

Most PHP problems come from old plugin or theme code, not from WordPress core. So before the WordPress PHP update itself, I update core, every plugin and the theme on staging. Developers usually fix compatibility issues in newer releases, and getting those fixes in first removes most of the risk.

While doing this I look for plugins that have not been updated in two years or more. Those are the ones most likely to break on a newer PHP version. If a plugin is abandoned, I plan a replacement now rather than after the site goes down.

Step 4: Check code compatibility

On bigger sites, or sites with custom code, I scan the plugins and theme for code that newer PHP versions no longer accept. A compatibility checker run on staging gives a quick list of warnings. It is not perfect and it flags some false alarms, but it points me to the files worth reading by hand.

Custom code is where I spend the most time. Things like old create_function() calls, deprecated each() loops, or functions that now throw errors on wrong argument types are common in older child themes and snippets. I fix those directly and keep a note of what changed.

Step 5: Switch PHP on staging and test properly

Now I change the PHP version on the staging copy. I usually move up one step at a time on very old sites, because jumping several versions at once makes it harder to tell which change caused a problem.

Then I test the parts of the site that make money or bring in leads:

• The homepage, a few inner pages and blog posts.
• Contact forms, including whether the email actually arrives.
• For stores: product pages, cart, checkout and a test payment.
• Logging in, the editor, and saving a post.
• Any custom features, like booking, membership or delivery options.

I also turn on debug logging on staging so I can read warnings in the log file instead of guessing. A clean log after clicking through the site is a good sign the WordPress PHP update is safe.

If something breaks, it is usually one plugin. I disable it to confirm, then update it, replace it or fix the code. If you are not sure which one is at fault, my guide on finding a WordPress plugin conflict walks through the same process.

Step 6: Run the WordPress PHP update on the live site

Once staging is clean, I repeat the same updates on live: core, plugins and theme first, then the PHP version. I pick a quiet time, usually early morning in the client’s time zone, and I stay on the site for the next hour to watch for errors.

Right after the switch I clear every cache: the caching plugin, any server cache and the CDN. Old cached pages can hide problems, or make it look like something broke when it did not.

Step 7: Know how to roll back

Even with a well-tested WordPress PHP update, I always keep a way back. In most hosting panels you can switch the PHP version back in a minute, so if a critical page breaks, I switch back first and debug second. Since I noted the old version in step 1, there is no guessing.

Rolling back is a short-term fix only. The old version still needs to go, so I fix the cause and try again within a few days.

Common problems after a WordPress PHP update

These are the issues I see most often:

• White screen or “critical error” message: almost always a plugin or theme function that the new PHP version does not accept. The error log names the file.
• Missing PHP extensions: the new version on the server may not have the same extensions enabled, such as imagick, intl or mbstring. Ask the host to enable them.
• Memory limit reset: some hosts store settings per PHP version, so a custom memory limit can drop back to the default.
• Deprecated notices on screen: these are warnings, not errors, but they should never show to visitors. Turn off display of errors on live and fix them over time.

The official WordPress guide to updating PHP is a good extra reference if you want to understand the background.

How often should you do this?

I check the PHP version on every site I support a few times a year, and I plan the next WordPress PHP update well before the current version reaches end of life. Done that way, it is a calm, planned job instead of an emergency after the host flips a switch.

If you would rather not deal with it yourself, I can check your site, test the new version on staging and handle the switch for you. Get in touch and tell me a bit about your site.

The post WordPress PHP Update: How I Upgrade PHP Without Breaking the Site appeared first on Nitin Rathod.