rsync is your friend.


Stuart Dallas
> On 26 Mar 2012, at 14:53, rene7705 wrote:
>> My last thread got derailed into a javascript and even
>> 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
>> $_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,
>> 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('
>> hehe
>> And get_php.php takes care of the nested
includes by massaging what it
>> retrieves. Or so is my
>> 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
>>, plus accompanying code, so I think I might
>> some
>> free tips here again.
> Don't do this. Use a central source to host your code by all means,
> 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

Reply via email to