There is a family of errors that nearly everyone running a site hits sooner or later. The blank screen when activating a plugin. The "file exceeds the maximum allowed size" when uploading a video. The import that stops halfway with no explanation. They look like different problems, but they are almost always the same thing: PHP has configured limits and your site is bumping into them.
The good news is that there are five or six values, they take ten minutes to understand, and most of them can be adjusted from the control panel without touching code.
Why these limits exist
Before raising everything to the maximum, it helps to understand what they are for. A shared server hosts many accounts on the same machine. If a single site could consume all available memory or leave a process running for ten minutes, it would take every neighbor down with it.
The limits are a seat belt. They also catch your own buggy code: an infinite loop with a time limit dies in thirty seconds; without one, it takes down the server. That is why the right answer is almost never "set everything to unlimited."
memory_limit: how much memory each process can use
This is how much RAM a single script may consume before PHP cuts it off. The classic symptom is a completely blank screen, or an error saying the allowed memory size was exhausted while trying to allocate a few more bytes.
It usually shows up when activating a heavy plugin, using a visual builder, processing large images, or running a backup plugin on a site that has grown a lot.
Reference values: 128 megabytes is enough for a simple WordPress. With a visual builder and a store, 256 is reasonable. If you routinely need more than 512, the limit is no longer the problem — something is consuming excess memory and it is worth finding out what.
upload_max_filesize and post_max_size: how big your uploads can be
These two go together, and confusing them is why many people change one, see no result, and get frustrated.
The first sets the maximum size of an individual file. The second sets the maximum size of the whole submission, which includes the file plus the rest of the form data.
The rule is simple: post_max_size must always be larger than upload_max_filesize. If you set both to 64 megabytes, a file of exactly 64 will fail, because the total submission weighs slightly more than the file alone. Leave the post value a few megabytes above.
One confusing detail: WordPress displays the smaller of the two values on the upload screen. If it says 8 megabytes while you configured 64, either the old value survives somewhere else, or the theme or a plugin is limiting it on its own.
max_execution_time: how long a script may run
This is the maximum time in seconds a script may run before PHP kills it. The symptom is a long process that always stops around the same point: an import dying at thirty percent, a backup that never finishes, a bulk update left half done.
The common default is 30 seconds. For maintenance tasks, 120 or 300 usually makes sense. But be careful: if your site needs more than 300 seconds to serve a normal page, the limit is not the problem. Something there involves bad queries or a server that cannot keep up.
A detail worth gold: this limit does not count time the script spends waiting on the database or an external service. That is why a process sometimes stops "earlier" than the clock suggests, and why you should also look at the web server timeouts, which do count total time.
max_input_vars: the limit that breaks menus
This is the hardest to diagnose because it produces no visible error. It defines how many variables a form may receive. When exceeded, PHP does not warn you: it silently discards everything past the limit.
The classic case is a navigation menu with a great many items: you save it, no error appears, and on reload the last twenty items are gone. The same happens with heavily loaded theme option panels or products with dozens of variations.
The default is usually 1000. Raising it to 3000 solves practically every real case.
Where to change these values
There are several places, and not all are available on every host. Here is the order of preference.
From the control panel. Most modern panels include a section to pick the PHP version and adjust its options from a form. This is the cleanest route, because the change applies to the whole account and survives site updates.
With your own configuration file. A text file in the site root listing the desired values, one per line. This works on most shared hosts.
From the WordPress configuration file. Useful for memory, by adding a line defining the limit. Handy when you have no access to the options above.
What you should avoid is putting these directives in the web server rules file: on many modern configurations it not only fails to work, it triggers a 500 error across the entire site.
How to verify the change took effect
Do not trust the form telling you it saved. Create a file with a single line printing PHP configuration information, open it in the browser, and look up the values. You will see both the active value and the configured one, which sometimes differ when something is overriding it.
Delete that file the moment you are done. It exposes detailed information about your server that serves nobody except someone trying to attack you. If you would rather not create it, the WordPress site health tool shows the same values from the dashboard.
When raising limits stops being the answer
There comes a point where stretching the numbers is covering up a real problem. If you need 1024 megabytes of memory to load the home page, if a backup takes more than ten minutes, or if you have to raise the execution time every couple of weeks, what your site is telling you is that it outgrew its plan.
At that point the conversation stops being about configuration and becomes about resources: more allocated memory, more processing power, fewer accounts sharing the machine. A semi-dedicated plan or a VPS solves at the root what no configuration tweak will.
It is worth checking which limits the entry plan ships with before signing up. At BanaHosting, for instance, the values come configured with headroom for a WordPress store and can be adjusted from the panel itself, without opening a ticket for every change. That matters more than it sounds: it is the difference between fixing something in two minutes and waiting on a support reply.