The PHP settings that quietly generate most support tickets

Spend enough years answering theme support and you stop reading the subject lines. "Demo import fails halfway." "My menu loses items when I save." "Uploading the header image does nothing." Four different reports, four different customers, one underlying cause: the server is configured for a blog from 2011.

The usual four

• memory_limit, the classic. A demo import loads posts, images and options in one request; 64M runs out somewhere in the middle and PHP dies without a useful message.
• max_input_vars, the cruel one. Save a large menu or an options panel with more fields than the limit allows and PHP silently truncates the POST. No error. Your settings just… partially save.
• upload_max_filesize and post_max_size. Usually noticed immediately, at least.
• max_execution_time. Anything batch-shaped dies at the thirty second mark.

max_input_vars deserves special mention because it fails so dishonestly. Nothing crashes. The user saves, sees a success notice, and discovers three days later that half their navigation is gone. From their side, that is a bug in your theme. It is not, but arguing about whose fault it is has never once fixed someone's menu.

A failure with no error message will always be blamed on the last thing that changed. That is usually your update.

Why telling people to "ask your host" does not work

The standard advice is to contact your hosting provider or edit php.ini. For a working professional who bought a theme to build a website, that is a request to open a support ticket with a company they may not have chosen, about a file they cannot see, to change a value they have not heard of.

Meanwhile the information they need to diagnose it (what the current values are, what they should be, and which file on this particular server actually wins) is scattered across a phpinfo() dump and a lot of guesswork.

So I am building a plugin about it

It is called Customize PHP Settings, and the idea is unglamorous: show every relevant directive in one table alongside its current value, PHP's default, and a recommended value, with a plain status of whether it is fine or needs attention. Then let the site owner change it from the admin, writing to whichever of .htaccess, .user.ini or php.ini the server will actually respect, and check writability before promising anything.

There is a diagnostics side too: loaded extensions, OPcache status, hit ratios, and the WordPress debug constants, since those are the next questions anyway.

The wider point

A lot of "product quality" is not in the product. It is in the distance between something going wrong and the user understanding why. Every directive in that table is a support ticket that does not get written, and a customer who does not spend an afternoon believing that software they paid for is broken.

That is a decent return for a settings screen.