User talk:MikeHutchens

Mike,

Thanks for your contribution, but I have a question I wanted to ask you about your change to PHP.ini: Why do you feel these instructions are "deprecated"? For certain "smallish" configuration changes, this is a legitimate way to effect changes in the environment, and is *much* simpler, and safer,for many users than compiling their own PHP. I'm in favor of removing the "deprecated" statement, but wanted to initiate a discussion before doing so. -- Rlparker 16:10, 2 Feb 2007 (PST)

It's not that I feel they're deprecated. Dreamhost no longer supports handling it this way. We urge all customers who need to modify PHP to follow the instructions for compiling their own PHP. -- MikeHutchens

That doesn't make a lot of sense. DreamHost never supported either customer PHP installations or custom PHP.ini files in the first place. As far as I can see, the policy hasn't changed one way or another. By saying the method is "deprecated", you are sending a message that DreamHost will (at some point) no longer allow custom php.ini files. I'm afraid the genie is very much out of the bottle on this one. It would be extremely difficult for DreamHost to impose this restriction without significant customer discontent. Are you in a position to offer clarification on this matter? -- Scjessey 11:58, 4 Feb 2007 (PST)

But aren't the Installing PHP4/5 instructions unsupported as well? (Edit conflict.) I would recommend that you use your Mikeh account in the future—or have this one sysopped—so that other editors can tell that you're from DH. --Emufarmers 12:01, 4 Feb 2007 (PST)

I suppose supported is the wrong word to use. We don't point customers to that page anymore (or aren't supposed to anyway) and compiling your own PHP is the recommended method. -- LOMG, silly rabbit MikeHutchens forgot to sign.

While DreamHost may not officially support any of the PHP modifications, I hardly feel that's reason enough to remove the article or mention that it's deprecated. It hardly is. While we may not recommend that users modify PHP.ini files it isn't something that's strictly forbidden... it's just not something that we recommend any longer. I'd leave things as they were, too. While one method may be recommended more than the other, it hardly justifies 'deprecating' an article in my eyes. Also, keep in mind that 'Mikeh' and 'MikeHutchens' are separate users. Both are DreamHost employees, however. --Mikes

BAM! That article is locked and reflects the fact that customers are no longer to use the php.ini method to modify their php config. How do ya like me now? --MikeHutchens

This is just plain silly. Who was it that said php.ini is not to be used anymore? I'm curious about the reasoning. Replacing just php.ini is much easier on our system (and storage) than compiling a full-blown custom PHP installation. These instructions could use some clean-up, but I just don't see any advantage in using the full-install instructions when all you need are small .ini directive changes (which, btw, could be done in .htaccess without an .ini file at all if we didn't have suexec locked up tight on that count.) --Sabrejack 14:43, 5 Feb 2007 (PST)

BAM! indeed. Just for the record, I don't know you at all, so I'll refrain from answering the , "How do ya like me now?" question, and just say that I don't understand your thinking, or what you are trying to accomplish. Why in the world would you rather a user compile a whole additional instance of PHP as opposed to simply using the DH supplied installation with their own .ini file? I can understand that, from a support standpoint, no one wants to deal with inexperienced users botching this, but surely those same users would have only more trouble with attempting a full install of PHP. When you look at the potential for someone screwing things up, surely using a modified .ini file with the existing DH-compiled PHP is "safer" for DH. Come on, don't be coy - what are you really trying to accomplish here? -- Rlparker 16:45, 5 Feb 2007 (PST)

We have had SO many more problems with php.ini than users compiling their own PHP. Modifying the php.ini breaks all kinds of stuff. My guess (not the official position) is that users are more comfortable modifying a file than compiling one, and end up getting in over their head, then they still ask us to fix what they broke. So... no php.ini mods. Seriously, I'm trying to be nice here. I could just say "cause Dreamhost said so" like other hosts might do. --MikeHutchens

I'm curious to know why restricting users from using a custom PHP.ini file will result in less "support" for custom jobs, whereas a custom PHP installation will not. I don't understand the reasoning behind this. If one form of PHP customization causes users to get "in over their head" and make them "ask us to fix what they broke" why won't another (like full custom PHP installs)? -Mikes

Thanks for sharing that, and I know what you mean - some of us who hang out on the DH forums have our share of "grief" with such users ourselves, so I understand what you are saying. I think your guess is probably right on the money, especially given that the most inexperienced users will likely not attempt a full install, but might feel like they can handle the .ini file modification. I'm sure that "fixing" what they "broke" is frustrating, but I'm not sure you don't risk the same scenario if those same users are instead pointed to a complete install - my thinking is they will bork that also, and put you in the same situation with even *greater* headaches. Maybe a better way to minimize the support burden is to improve the article in question.

I appreciate your situation (and that you are trying to be nice!). As for the, " I could just say 'cause Dreamhost said so' like other hosts might do," statement, I'll agree that you (DH?) could certainly take that position, though Dreamhost has never been known for those kinds of postures - and I don't think DH is well-served by starting to operate "like other web hosts might". ;-) So is it now DH's "official position" that there be "no php.ini mods", and, if that is the official position, how do you handle those using such mods at present and/or those that continue to create such setups going forward? -- Rlparker 18:21, 5 Feb 2007 (PST)

That's a good question. I don't think we're gonna ask users who have already done the php.ini modifications to change their setup (especially if it's already working well). I'll ask my lead about it tomorrow though. --MikeHutchens

You'll have to forgive me for being blunt, but I think this "all of a sudden" bloody-minded approach is really silly. Support must be completely deluded if they think a complete PHP install is going to be easier to manage than simply doing a custom PHP.ini. I'll wager that support gets fewer problems with full installs because there are far fewer attempts at it. The inevitable consequence of this policy is going to be a sharp rise in custom PHP installations, and a corresponding sharp increase in support queries - irrespective of whether or not DreamHost offers official support.

I'm willing to further wager that a good proportion of people attempting to do custom PHP.ini files are trying to get around the ludicrously-small PHP file upload allowance. Perhaps by globally raising that allowance from 7Mb to something north of 50Mb, there would less of this custom malarkey in the first place. 7Mb was okay when it was just pictures people were uploading, but now you have to consider audio and video as well. -- Scjessey 06:25, 6 Feb 2007 (PST)