On 26 Mar 2012, at 14:53, rene7705 wrote: > My last thread got derailed into a javascript and even photoshop > discussion, and while I can't blame myself for that really, this time I > would like to bring a pure PHP issue to your scrutiny. > > I run several sites now, on the same shared hoster, but with such a setup > that I cannot let PHP require() or include() code from a central place > located on another domain name on the same shared hosting account, not the > normal way at least. > $_SERVER['DOCUMENT_ROOT'] is a completely different path for each of the > domains on the same hosting account, and obviously you can't access one > domain's directory from another domain. > > Hoster support's reply is A) I dont know code, B) You can't include code > from one domain on another and C) use multiple copies, 1 for each domain > > But that directory (my opensourced /code in the zip on > http://mediabeez.wsbtw), takes a while to update to my hoster, many > files. > Plus, as I add more domains that use the same code base, my overhead and > waiting time increases lineary at a steep incline. > > So.. Since all of this code is my own, and tested and trusted, I can just > eval(file_get_contents(' > http://sitewithwantedcode.com/code/get_php.php?file=/code/sitewide_rv/autorun.php')) > hehe > And get_php.php takes care of the nested includes by massaging what it > retrieves. Or so is my thinking. > > The problem I'm facing, and for which I'm asking your most scrutinous > feedback, is: > How would you transform _nested_ require(_once) and include(_once)? I > haven't figured out yet how to transform a relative path include/require. > What about for instance a require_once($fileIwantNow)? > I do both in my /code tree atm. > > For my own purposes, I could massage my own PHP in /code/libraries_rv and > /code/sitewide_rv manually, but I'd also like to be able to include a > single copy of the 3rd party free libs that I use in > /code/libraries(/adodb-5.10 for instance). And god knows how they might > include and require. > > Plus, I'd like to turn this into another free how-to blog entry on > http://mediabeez.ws, plus accompanying code, so I think I might find some > free tips here again. Don't do this. Use a central source to host your code by all means, but create constantly updated copies on every server that uses it. Since I use git for source control I make use of the submodule feature to make this simplicity itself. It's worth investing time in building the processes that ensure consistency between your various environments. The best ops strategy is the lazy op's strategy! Set up cron scripts on each server to update that code periodically so everything is always up to date. I wouldn't recommend that unless you have good testing procedures in place before your code hits production, but from what I've seen I find the highly doubtful. However, sharing code at runtime over http is a very very very bad idea. Even farms with hundreds or thousands of servers, all running the same application on a fast local network, don't share code in this way. Each server has its own copy of the code, and it's the deployment processes that ensure they're kept up to date. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
