It sounds like you are getting the hang of things, and I do not want to sound disparaging or critical, but I think you should know that:

1) register_globals being set on is a significant security risk for your site. Many common exploits use this as an attack vector, and you should very carefully consider this before deciding to turn them back "on".

2) Dreamhost's disabling of allow_url_fopen is for your protection. Again, this "feature" of php can easily leave your site vulnerable to exploitation unless some fairly sophisticated and thorough programming is in place to filter what is retrieved from a remote site.

3) The combination you describe - enabling register_globals *and* enabling allow_url_fopen for your sites (particularly an e-commerce site) can be a recipe for potential disaster.

This risk is greatly magnified by your own description of your skills. A good programmer with a good understanding of the issue(s) involved can mitigate some of these risks, but your reliance on others' code coupled with your lack of programming experience will make it difficult for your to evaluate the weaknesses that may be in that code. In short, you may be exposing yourself to considerable risk by modifying php to work in the way you describe.

Consider also that, as a citizen of a shared server, your security practices , good or bad, have the potential to impact others who share your server. Modifying the environment to remove/disable/thwart security protections DH has installed for the protection of all is a serious matter, and the responsibility to "know what you are doing", in order to do this without negatively exposing others, is very real.

To my way of thinking, doing this is a bit like disabling a safety feature on a passenger bus for your own convenience - maybe if you are an automotive engineer and are completely competent to do it safely, no harm would result; if you are just another passenger, doing such a thing without knowing the risks could be disastrous.

All of this is one of the reasons that DH support will *not* provide assistance with such things. The fact they they will *let* you do it at all presumes that, if you have sufficient knowledge to make these kinds of changes, you are likely to have sufficient knowledge to make them wisely.

The problem with the wiki article, and (to some degree) help of this type from the Forum, is that it "short-circuits" that "built-in" barrier to ill-advised modifications. This can have much the same effect on the security of the server as placing a penny in a fuse holder has on the electrical system of a house.

For all these reasons, and since you indicated you were running a e-commerce site, I respectfully suggest that you consider hiring an experienced php developer/ programmer to review your applications, the related implications of your proposed environment changes, *and* implement whatever changes are required/indicated rather then trying to "do it yourself".

These changes are much more significant, to both *your site* and those of others sharing your server, than the wiki's example of changing the max_upload_filesize, and should *not* be approached in the same manner.

None of this is intended to be critical of you, and I hope you read this in the spirit in which it is offered. Just because something *can* be done, does not mean that it *should* be done, and I really want you to understand the risks involved in what you are trying to do.

I wish you, and your site, only the best!

--rlparker