Talk:PHP.ini

PHP 5.3 Steps not Working
I put my file called "phprc" in my ~/php/5.3/ (same home dir that my web site is installed under) and I still get PHP 5.2.15 showing up as the version number. Is there something I am missing? --Etoreo 22:27, 29 March 2011 (PDT)


 * Yes, you need to switch to PHP 5.3 from the Panel. Also, the phprc goes in .php/5.3 (with a leading dot), not php/5.3.

Clarification Needed
Will doing this force DH's PHP to look to this PHP.ini file from now on or for this to work will I have to install my own php binary?

- 3choBoomer - 2006-06-28


 * This system is basically making your own copy of the DH binary, and should use your php.ini file. --Sabrejack 11:24, 6 Nov 2006 (PST)

I've fixed a few little errors and typos on this page, but there is one big typo to making the whole thing work that I think I found. I hesitate to change this myself without some feedback, however, because I have only a small amount of unix experience and absolutely no crontab experience.

The current wiki page tells you to put this line in your crontab file:

@weekly /home/myusername/php_update

However, it looks like if you've followed the rest of the directions on the page, the line should be:

@weekly /home/myusername/php-update.sh

Any other thoughts?

-

benanna 6-20-2006


 * You're correct, I've fixed that line. -- Sabrejack 13:47, 21 Jun 2006 (PDT)

Wiki vs forum entry
For PHP4: CGIFILE="$HOME/[your website directory]/cgi-bin/php.cgi" INIFILE="$HOME/[your website directory]/cgi-bin/php.ini" cp /dh/cgi-system/php.cgi "$CGIFILE" cp /etc/php/cgi/php.ini "$INIFILE" perl -p -i -e ' s/.*post_max_size.*/post_max_size = 100M/; s/.*upload_max_filesize.*/upload_max_filesize = 100M/; ' "$INIFILE"
 * 1) /bin/sh

While Forum has:

CGIFILE="$HOME/domain.com/cgi-bin/php.cgi" INIFILE="$HOME/domain.com/cgi-bin/php.ini" cp /usr/local/bin/php "$CGIFILE" cp /etc/php/php.ini "$INIFILE" perl -p -i -e ' s/.*post_max_size.*/post_max_size = 100M/; s/.*upload_max_filesize.*/upload_max_filesize = 100M/; ' "$INIFILE"
 * 1) /bin/sh

I tried the code from the wiki and got: [peso]$ ./php-update.sh : command not foundne 6:

Php on the site wouldnt work for me with the code in the wiki....It works with the code from the forum.


 * The code in the wiki article is now correct -- Rlparker 13:42, 7 Feb 2007 (PST)

New file creation using SSH
I was wondering how to create a new file, in particular php-update.sh from within the shell.


 * As per the note at the top, these instructions are highly advanced and you are expected to know your way around the shell.   The simple answer is to type "emacs php-update.sh" in the directory you want to make the file in.  --Sabrejack 11:26, 6 Nov 2006 (PST)


 * Well, i wouldn't call it highly advanced, but i would call it advanced enough to discourage first-timers to try this.
 * I ended up creating php-update.sh in a local test editor, then FTP'ed to my server. The rest showed itself. I just had no experience with creating files in textmode under Linux, that's all (i'm a GUI addict, can you tell?).
 * Anyway, the method as described did enable me to use a more secure php.ini since on the server i am on, register_globals are still enabled, causing Joomla 1.0.11 to sound the alarm.
 * I also wanted selected people to be able to upload large files though HTTP, 7MB didn't cut it and i did try setting a higher value using .htaccess but didn't work, so the 100MB limit as set in the new php.ini file is very welcome.
 * Other than that, i have made no modifications whatsoever. I know how important security is for an internet-connected server...
 * --Balaamsmiracle 16:18, 6 Nov 2006 (PST)


 * Yeah, I know it's not actually highly advanced, I just wanted to scare the newbies away from attempting it. =) --Sabrejack 16:40, 6 Nov 2006 (PST)

---

I followed this and dreamhost had to turn off my site.... so just be careful.


 * Enabling the previously disabled parts of PHP can be dangerous and should only be attempted by advanced users who can look after and keep their scripts running nicely on a shared server. Definitely be careful!  --Sabrejack 17:07, 20 Nov 2006 (PST)

A better practice - using rsync
It would be more efficient to use "rsync" than "cp" as it will copy only when the local version is old:

CGIFILE="$HOME/[your website directory]/cgi-bin/php.cgi" INIFILE="$HOME/[your website directory]/cgi-bin/php.ini" rsync -a /dh/cgi-system/php.cgi "$CGIFILE" cp /etc/php/cgi/php.ini "$INIFILE" perl -p -i -e ' s/.*post_max_size.*/post_max_size = 100M/; s/.*upload_max_filesize.*/upload_max_filesize = 100M/; ' "$INIFILE"
 * 1) /bin/sh

A better practice - $PHPRC shell variable
You could build a wrapper script and have it set the PHPRC variable to where your php.ini file is. This way, you don't have to rsync or cp the actual php binary file. I'm doing it with the php5 fastcgi. My .htaccess file is:

AddHandler fastcgi-script fgc fcgi fpl AddHandler php5-fastcgi .php Action php5-fastcgi /cgi-bin/php5-wrapper.fcgi

The php5-wrapper.fcgi has:

PHPRC="/home/username/domain/cgi-bin" export PHPRC PHP_FCGI_CHILDREN=2 export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=5000 export PHP_FCGI_MAX_REQUESTS exec /dh/cgi-system/php5.cgi
 * 1) !/bin/sh

And the ini file is located in /home/username/domain/cgi-bin. I used this to successfully install eAccelerator and am working on APC (so I can compare the two) --Trevan 11-28-2006

This method was the only method I could get to work on Dreamhost PS on the new cluster. My old method of modifying the .htaccess was borked by the move, and the official method in the wiki did not work. This worked great though! Thanks! -Lexicon 04:07, 3 November 2008 (UTC)

default php.ini
What are default/standard settings file "php.ini" used on servers dreamhost? Where I can find used file by standards "php.ini" on servers?


 * If you log in to the shell, you should be able to examine the current DreamHost PHP.ini file at   -- Scjessey 13:04, 17 Jan 2007 (PST)

php-copy.sh and php-update.sh
It seems that php-update.sh when we remove the "cp" command it doesn't take the new php.ini php-copy.sh should be placed in the cronjob.


 * The difference between php-copy and php-update is that php-copy will overwrite your php.ini file, while php-update will not. You don't want your changes to be overwritten on a weekly basis, so php-update is the one that should be placed in the cronjob. -- Draknek 07:40, 28 July 2007 (PDT)

Aren't the parts referring to the 'ini' file useless in the update script? Since a copy of the ini file isn't copied except the first time, the edits to the file are pretty useless. I could see commenting them out, then un-commenting them if you need to change the values later on. --

Copying php.cgi vs. installing your own version
This page says "DreamHost technical support does not recommend or will not provide any support for this method, so you should follow these instructions at your own risk. The preferred method is to install your own version of PHP, although that is also an unsupported approach."

Why is installing your own version of PHP preferred? If you follow the instructions on this page, it will be updated automatically, whereas if you install your own, you have to manually update it. -- Draknek 07:34, 28 July 2007 (PDT)


 * That is a really good question, and one that I have not been able to get an authoritative answer regarding from any DreamHost staff. If you track through the article history, you will see there was considerable discussion about all of that, and numerous revisions made, before the current version of that verbiage was agreed upon.  At this point, all I can say is what I know:  DreamHost support no longer recommends the use of a copied/modified php.ini and they *insist* that the statement about"The preferred method is to install your own version of PHP, although that is also an unsupported approach" remain in the article. -- Rlparker 13:46, 29 July 2007 (PDT)

Recent edits to article - one method, but no cron update, etc.
While I understand the logic of only offering one version of doing this, is this really the "best" way to go with these kinds of articles? For example, the recenly deleted methodology included the creation of a cron job to keep the php.cgi updated in sync with the DreamHost installed php.cgi, and this seems like it would be useful for some users. Is there really harm in having more than one way to do some things in the wiki? -- Rlparker 15:19, 18 August 2008 (UTC)

Redirect from Custom PHP page
Hi, all

I'm a non-technical person who has been relying heavily on the information at the bottom of the old Custom PHP ini page. It was the information under the alternate non-shell method and without it I would not have been able to install ioncube on 5 or 6 of my domains. Can we reinstate that information for others like me or give it it's own page. Thanks

Proper .htaccess entry - working for me 09.11.2008
The wiki shows the entry you need to add as: Action php-cgi /cgi-bin/php-wrapper.cgi Action php5-cgi /cgi-bin/php-wrapper.cgi

To get it working (after searching for hours) I entered: AddHandler php-cgi .php Action php-cgi /cgi-bin/php-wrapper.cgi Action php5-cgi /cgi-bin/php-wrapper.cgi

Keep in mind, I am relatively noobish with unix shell commands and cgi scripts so I'm sure there's a workaround somewhere in the wrapper file, however this worked perfectly for me and loaded my custom .ini file as expected.


 * While I'll assume the reason it was omitted was due to the nature of this process being deemed advanced, I still find it necessary.

Private Server issue: xcache and php.ini
I use a custom php.ini in order to use ioncube.

After moving to Dreamhost PS I was having problems with xcache disabling ioncube. I finally figured out that enabling xcache disables the custom php.ini.

As a workaround the following steps work to use a custom php.ini with xcache on Dreamhost PS.

1. In your PS control panel enable xcache 2. Follow existing instructions to install a custom php.ini. It won't work yet, but that's okay... 3. In your PS control panel disable xcache 4. Now make any changes to your custom php.ini

Xcache is setup in server's php.ini, so by saving a copy of the php.ini while xcache is enabled you grab all of the needed xcache settings. Once xcache is disabled in the control panel your server uses your custom php.ini again, which now includes the xcache settings.

Also, if you're using ioncube, make sure the ioncube call is before the xcache call in your php.ini.

When does apache restart?
After following the instructions for my domain, how long do I need to wait for the server to restart, and my new PHP.ini file to take effect?

You need to restart PHP, this wiki page actually says how to do it, but it's buried inside another step (took me 2 days to figure this out). The command is: killall php53.cgi  -- do this from the shell. Alternately, you can wait about 5 minutes. Doing killall makes the new changes take effect instantly, though. Elecmahm 10:43, 29 September 2011 (PDT)