Why Your WordPress PHP Settings Aren’t Working (And How to Fix It)



If you’ve ever used a WordPress plugin that suddenly flashes a warning—”PHP Time Limit: 300″—or checked your Site Health tool only to find your server values aren't what you set them to be, you know how frustrating it can be.

You log into your hosting panel (like Hostinger’s hPanel or a cPanel), increase max_execution_time to 3600, and set memory_limit to 1024M. Yet, WordPress stubbornly reports a lower value.

What’s going on? Is your hosting broken? Is it a WordPress bug?

The good news is, it's usually neither. The problem lies in a hidden hierarchy of configuration files, where one setting is overriding another. In this guide, we'll walk you through why this happens and exactly how to fix it, especially for users on popular hosts like Hostinger.

Understanding the PHP Configuration Hierarchy

The first thing to understand is that there's a pecking order for PHP settings. A setting defined in one file can be completely ignored if another, more powerful file overrules it.

Here is the typical hierarchy, from most powerful to least powerful:

  1. Global php.ini: This is the master server configuration file. On shared hosting, you have no access to this.
  2. .user.ini: This file sets rules for a specific directory (e.g., your entire public_html folder). It’s a common method used by modern hosts like Hostinger and can override almost everything else. This is the most common culprit.
  3. .htaccess: This file can also define PHP rules, though it's an older method for these specific settings.
  4. wp-config.php: You can use code within WordPress’s own configuration file to set PHP values.
  5. Hosting Panel (hPanel/cPanel): Your hosting panel is just a user-friendly interface. When you change a setting here, it tries to modify one of the files above. Sometimes, it fails or gets overridden.

So, even if you set max_execution_time to 3600 in hPanel, if a .user.ini file exists and has it set to 360, the .user.ini file wins.

The Step-by-Step Fix: How to Force Your PHP Settings

Let's work our way through the solutions, starting with the most likely fix.

Method 1: The .user.ini File (The Prime Suspect)

This is the most effective method on modern hosting environments like Hostinger. Even if you can't find this file, creating it often solves the problem instantly.

  1. Log into your hosting account and open the File Manager.
  2. Navigate to the root directory of your WordPress installation (usually public_html).
  3. Make sure “Show Hidden Files” is enabled in your File Manager's settings. Files starting with a dot (.) are hidden by default.
  4. Look for a file named .user.ini.
    • If you find it: Edit the file. You will likely see something like this:
      max_execution_time=360
      max_input_time=360
      memory_limit=512M
      Change these values to your desired settings.
    • If you DON'T find it: This is key! You should create it. Click “New File,” name it exactly .user.ini, and add the following lines:
      max_execution_time=3600
      max_input_time=3600
      memory_limit=1024M
      upload_max_filesize=64M
      post_max_size=64M
  5. Save the file. Wait a minute or two, then go back to your WordPress Dashboard and check Tools > Site Health > Info > Server. The new values should now be reflected.

Method 2: Forcing Settings with wp-config.php

If the .user.ini method doesn't work, you can try to force the settings directly from within WordPress.

  1. In your File Manager, find and edit the wp-config.php file.
  2. Scroll down until you see the line:
    /* That's all, stop editing! Happy publishing. */
  3. Just above that line, add the following PHP code:
    ini_set('max_execution_time', '3600');
    ini_set('max_input_time', '3600');
    ini_set('memory_limit', '1024M');
  4. Save the file and check your Site Health again.

Note: This method works well for max_execution_time but can sometimes be blocked by the server for memory_limit, which leads us to our final point.

What If Nothing Works? The “Hard Limit”

You might follow all these steps and find that one value—often memory_limit—refuses to change. For instance, you set it to 1024M, but it stays stuck at 512M.

This indicates a hard limit imposed by your hosting provider on your specific plan. Even if your plan advertises “2GB RAM,” the host may cap any single PHP script at 512MB to ensure server stability for all users. It's a common practice in shared hosting environments.

If you suspect this is the case, the only way to be sure is to contact your host's support team. Ask them directly:

“Hi, I'm trying to set my PHP memory_limit to 1024M, but it appears to be capped at 512M in my WordPress Site Health. Can you confirm if there is a hard limit on my hosting plan?”

They can give you a definitive answer.

Final Thoughts

Navigating server configurations can feel daunting, but it usually comes down to finding which file has the final say. For most users on modern platforms like Hostinger, the .user.ini file is the key. By either editing it or creating it yourself, you can finally take control of your WordPress environment and get back to what matters: creating great content.

Frequently Asked Questions (FAQ)

Here are answers to some common questions that might come up as you work through these settings.

1. What exactly is max_execution_time and why do I need to increase it?

Think of max_execution_time as a stopwatch for any task your website performs in the background. By default, a server gives a PHP script (like a plugin) a limited amount of time to complete its job, often 30 or 60 seconds. For simple tasks, this is plenty.

However, for heavy-duty operations like generating a full site backup, importing a large number of products into WooCommerce, or applying complex changes with a page builder, the script needs more time. If it hits the time limit, it stops, leaving the task incomplete. Increasing this value gives those important, long-running tasks the time they need to finish successfully.

2. Is it safe to set these values really high? Should I just set them to 9999?

While it's technically possible, it's generally not recommended to set them to an extremely high number permanently. A high max_execution_time is like leaving a door wide open. While it's useful when you need to move big furniture (run a big task), leaving it open all the time could be a security risk. A poorly coded or hijacked script could get stuck in a loop and use up all your server resources, potentially crashing your site.

A good practice is to set the values to what you reasonably need. For most tasks, 300 or 600 seconds is more than enough. Only use a value as high as 3600 (1 hour) if you are running a specific, trusted process that you know will take that long.

3. I increased the time limit, but my large file upload still fails. Why?

This is a very common point of confusion! The time limit is only half of the story for uploads. Uploading files involves two other crucial PHP settings:

  • upload_max_filesize: The maximum size for a single file.
  • post_max_size: The maximum size of all the data in a single request (which includes the file and other form data).

For a file upload to work, post_max_size must be larger than upload_max_filesize. If you want to upload a 50MB file, you should set your configuration like this:

; In your .user.ini file
upload_max_filesize = 64M
post_max_size = 65M

Notice post_max_size is slightly larger. You would add these lines to your .user.ini file along with the max_execution_time setting.

4. I edited one of these files and now my website shows an error! How do I fix it?

Don't panic! This almost always happens because of a small typo. The fastest way to fix it is to undo your last change.

  1. Go back to the File Manager.
  2. Open the file you just edited (.user.ini or wp-config.php).
  3. Carefully check the lines you added. Look for a missing semicolon, an incorrect quote mark, or a misspelled word.
  4. If you can't spot the error, simply delete the lines you added and save the file. Your site will immediately return to its previous state.

5. Why do hosting providers like Hostinger limit these settings in the first place?

It all comes down to stability and fairness in a shared hosting environment. Think of a shared server as an apartment building where everyone shares the main power and water supply. If one resident decides to run a massive, power-hungry machine 24/7, it could cause brownouts for everyone else.

By placing sensible limits on things like memory_limit and max_execution_time, hosting providers ensure that one website can't accidentally (or intentionally) consume all the server's resources and negatively affect the other “residents.” It's a protective measure that keeps the server stable for everyone. This is also why moving to a VPS or Cloud Hosting plan is the next step when you need to escape these shared limits.

A Quick Disclaimer

The information provided in this guide is for educational purposes and is based on our own testing and experience. We've taken great care to ensure its accuracy and safety.

However, editing core website files like .user.ini or wp-config.php always carries a small amount of risk. Before making any changes to your site's code, we strongly recommend that you perform a full backup of your website files and database. A recent backup is the fastest and safest way to restore your site if anything unexpected happens.

By following the steps in this article, you agree that you are doing so at your own risk. The author and this website will not be held responsible for any potential issues, including but not limited to data loss, site downtime, or conflicts that may arise on your website.

If you are not comfortable performing these steps yourself, we highly recommend seeking expert assistance. For server-specific issues, your hosting provider is a great first point of contact. For direct, hands-on help with your WordPress site, consider hiring a qualified developer. If you're looking for assistance, you can reach out to me via my contact page, and I would be happy to help you sort it out.

Leave a Reply

Your email address will not be published. Required fields are marked *