Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I set up a wordpress server from a fairly standard Ubuntu 9.10 for a class and they're constantly running into problems with the default PHP.ini settings. First memory settings were too low, then the file upload limits were too small, etc. And more concerning was a wordpress wide blank page that I suspect was killed for ram consumption but turning on php errors in php.ini didn't reveal anything!

I'm not familiar with shared hosting, but I feel there's a way such places allow users to edit such things without needing me to intervene and restart Apache.

share|improve this question
up vote 2 down vote accepted

Technically, you can't fix the php.ini file while it's running (iirc it's only read when apache starts), but your don't actually have to change it to make your changes.

ini-set allows you to change the option within the code. It's a bit tedious to set one option at a time, so they added parse_ini_file to...well, parse an .ini file.

You can also over-ride the values with an .htaccess file, using the php_flag directive.

share|improve this answer

You probably don't want to let your users touch PHP.ini settings (particularly since this requires AllowOverride Options or AllowOverride All to be set, which can open up a lot of ways for your users to create security holes.

When I was doing the ISP/Shared Hosting thing I set relatively generous system-wide limits and users who routinely hit those limits could buy a higher class of service (at which point I or someone from the admin team would edit the Apache configuration for their specific virtual host & increase their limits).

This has two major advantages: Security (Your users can't glom all your memory or upload some obscenely large file and fill your disk) and Cash Flow (Users taking a greater share of resources are forced to pay for them), and the additional demands on your time are relatively minimal. As a bonus you also know what resources you're committing, so you know if you're over-committing the server to a point where you may need to bring up a new one and migrate some clients.

share|improve this answer
I appreciate the market oriented solution, but we're within the same firm (yay Coase's theorem). – jldugger May 18 '10 at 20:23
I would still have visceral objections to allowing users to set PHP options via .htaccess -- it only takes one user deciding that a sledgehammer is better than a scalpel & you wind up with all sorts of issues (and as the admin it's obviously your fault :). That said since it's in the same organization the AllowOverride directive or loosening up restrictions so you can implement Satanicpuppy's suggestion aren't quite so bad. – voretaq7 May 18 '10 at 22:12

Run 'em via FastCGI so you can keep everything isolated to their own UID (suPHP/suExec). Then, provide a php wrapper that loads a custom ini file. That will let them edit their own settings, but keep everything constrained to their own UID. I've got a handful of Wordpress installs working like this (though I also set memory limits per-user).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.