PHP Code Management

[alexcn]

Morning Guys and Girls,

Just trying to pick your brains on maintaining PHP code: I have multiple osCommerce sites all with different databases and on different domains but essentially using (aside from configuration, image, and stylesheet files) the exact same set of PHP files. Anyone that uses OSC will know there are a huge number of contributions available to enhance OSC features, however managing the installing of these across these multiple sites is becomming a major pain in the bum.

Does anyone know of any software that will roll out these changes automatically or at least manage the changes / versions control on identical code sets?

Any help would be greatly appreciated,

Alex

[MrPhil]

Hmm. So you want to install your latest changes on some master osC site, and then press a button and all the new and changed files propagate to the subsidiary sites? This would allow you to test and install on one site, and when you're happy, spread the changes.

 

There are a number of ways this could be done, assuming that the various sites are all under one account on one server, so that you could just copy (cp) a file from one place to another. "make" could do it, but would probably be overkill just to do a copy. A shell script could take a list of files (with full path from the site root) and test if the master copy is younger than the site copy (or the site copy doesn't exist), and if so, copy it over (preserving the timestamp). Selected configuration files and such could simply issue a warning that those files should be manually compared and updated. You might start with a list of files (ls -aR) and use a simple editor to remove images, etc. and add a function call (depending on the shell script language you pick) on each line. That function would test the relative ages and existence and do the copy if necessary. Another function call could be used for configuration files that just get warnings, and still another one might be used to remove no longer needed files. It could also be done with, say, a PHP script and run from the command line, but I'd put it in admin and password protect the admin directory. Lots of possible ways to do it.

 

The very first file that gets updated might be the copy script itself, or a list of files to operate on. You might go into each site and fire off a script that first copies over the update script, and then runs it, so it's still a one-click process. Your script probably ought to log everything it does, in case something goes wrong. It might also be good to shut down each site as your script is working on it -- such as swapping in a temporary .htaccess that redirects to an error message page.

 

If the sites are under different accounts, or on different machines, it might get a bit more complicated, but some sort of remote copying should be possible.

[alexcn]

Dear MrPhil,

 

Many thanks for your response: you seem to have understood the problem perfectly and your solution is certainly something that I will look into. I was thinking last night (and hence my other posting about shared code) that since all of these files will be the same would it not be easier (and I am talking as a novice here ...) to somehow just have a single copy of all the files on a "master OSC" installation to use your analogy and then have some kind of "include" that basically just always uses these shared libaries? I dont know PHP enough to do this but just looking into the feasibility.

 

Thanks in advance,

 

Alex

 

Hmm. So you want to install your latest changes on some master osC site, and then press a button and all the new and changed files propagate to the subsidiary sites? This would allow you to test and install on one site, and when you're happy, spread the changes.

 

There are a number of ways this could be done, assuming that the various sites are all under one account on one server, so that you could just copy (cp) a file from one place to another. "make" could do it, but would probably be overkill just to do a copy. A shell script could take a list of files (with full path from the site root) and test if the master copy is younger than the site copy (or the site copy doesn't exist), and if so, copy it over (preserving the timestamp). Selected configuration files and such could simply issue a warning that those files should be manually compared and updated. You might start with a list of files (ls -aR) and use a simple editor to remove images, etc. and add a function call (depending on the shell script language you pick) on each line. That function would test the relative ages and existence and do the copy if necessary. Another function call could be used for configuration files that just get warnings, and still another one might be used to remove no longer needed files. It could also be done with, say, a PHP script and run from the command line, but I'd put it in admin and password protect the admin directory. Lots of possible ways to do it.

 

The very first file that gets updated might be the copy script itself, or a list of files to operate on. You might go into each site and fire off a script that first copies over the update script, and then runs it, so it's still a one-click process. Your script probably ought to log everything it does, in case something goes wrong. It might also be good to shut down each site as your script is working on it -- such as swapping in a temporary .htaccess that redirects to an error message page.

 

If the sites are under different accounts, or on different machines, it might get a bit more complicated, but some sort of remote copying should be possible.

[MrPhil]

I know that sharing a single copy of the PHP files for multiple sites has been discussed before, but I don't think it came to a satisfactory conclusion. I think it was for osC, but might have been for another product (forum). When the server looks at a certain address for code to run, it expects to find the files there. I suppose you could set up "symbolic links" (soft links) for all the PHP files, all linking back to the central repository, but that seems to be swatting a gnat with a sledgehammer. Whenever files are added or dropped, you'd have to go and update the links at each site. Plus, execution would be slowed down, as each link has to be followed to get to the real code.

 

Is your objective to conserve server disk space, or just to keep a single copy for ease of updating? The PHP files don't really take up that much space, so I don't think it's worth pursuing that objective. It would probably be easier to install and maintain a master copy, and copy files to each subsidiary site as updates are made (as discussed before). You might also look into "multiple store" contributions that make it look like multiple stores are operating out of a single site. I haven't tried doing it, but it might be possible to "park" different domains to point to the master domain, and use .htaccess URL rewriting to point to different configuration files based on which domain you come in on (%{HTTP_HOST}). That might not be too painful (famous last words). I wonder if anyone's successfully done that?

[alexcn]

Morning Phil,

 

Thanks for your prompt and detailed response once again, as you guessed: doing this to save disk space is not something that concerns me as I have ample space on my own cluster to accomodate what I need this is purely for ease of maintenance of the various files thats all and re-thinking your response here and before you are probably right in that actually setting up a batch copy of the site (taking the site into maintenance mode first) is probably the way forward however I just "felt" that a shared code libary would be the way forward. Having said that: I am guessing that I COULD setup a shared library for everything in the [include] file structures as these are never directly referenced aside from being merged into the script at run time by way of the include or require statements. This would leave just the root directory PHP files for site and admin functions only held in each domain: however I am guessing that it is THESE that frequently charge for the contributiosn anyway! *sigh*

 

I am guessing someone / somewhere has tinkered with this before but whether it was successful: who knows I guess.

 

Regards,

 

Alex

 

I know that sharing a single copy of the PHP files for multiple sites has been discussed before, but I don't think it came to a satisfactory conclusion. I think it was for osC, but might have been for another product (forum). When the server looks at a certain address for code to run, it expects to find the files there. I suppose you could set up "symbolic links" (soft links) for all the PHP files, all linking back to the central repository, but that seems to be swatting a gnat with a sledgehammer. Whenever files are added or dropped, you'd have to go and update the links at each site. Plus, execution would be slowed down, as each link has to be followed to get to the real code.

 

Is your objective to conserve server disk space, or just to keep a single copy for ease of updating? The PHP files don't really take up that much space, so I don't think it's worth pursuing that objective. It would probably be easier to install and maintain a master copy, and copy files to each subsidiary site as updates are made (as discussed before). You might also look into "multiple store" contributions that make it look like multiple stores are operating out of a single site. I haven't tried doing it, but it might be possible to "park" different domains to point to the master domain, and use .htaccess URL rewriting to point to different configuration files based on which domain you come in on (%{HTTP_HOST}). That might not be too painful (famous last words). I wonder if anyone's successfully done that?

[WebDev22]

Hey Alex,

 

I'm glad I found this thread and am working on accomplishing the same thing, hence the thread I started yesterday: http://www.oscommerce.com/forums/topic/349271-maintaining-one-set-of-templates-for-two-sites/. My motivation for doing this is the same as yours, to gain efficiencies, especially when adding contributions. It would be nice to add a contribution to one site and the other benefits as well.

 

Did you make any progress?

 

Brett

[WebDev22]

Also, because both of these sites have been live for quite some time, getting the two sites synchronized is quite a task.

[MrPhil]

I would suggest writing a shell script to copy a fixed list of files over from the "master" into a "slave" store installation. As a very Quick and quite Dirty way, in the slave store, start with a ls -aR command and remove the configure.php files and various category and product related files that don't need to be copied over. If using different themes or add-ons, remove all affected files from the list. You should end up with a list of files that you want to be the same in all stores (mostly .php and some image files). Write a shell script to read this file list one line (file) at a time and execute some kind of copy command from the master to the slave. Depending on whether the master is on a different machine, whether the remote machine is nfs-mounted, and what its file permissions are, you might have to do a cp, rcp, or something else. Try to find a way to do it without having to enter a password each time! It would be good to shut down the "slave" store before running the copy script, so customers aren't caught mid-way through a checkout or something. Depending on what needs to be done, that might be part of the copy script.

 

Alex, did you end up writing such a thing?

[♥FWR Media]

What a very interesting thread.

 

Aside from the complexity of achieving the task of master/slave management, osCommerce makes this extremely difficult simply because the themeing touches so many files and functionality is not decoupled.

[WebDev22]

What a very interesting thread.

 

Aside from the complexity of achieving the task of master/slave management, osCommerce makes this extremely difficult simply because the themeing touches so many files and functionality is not decoupled.

So far I've noticed the following files need to remain unique for each:

- header.php

- configure.php

- includes/footer.php //contains Google Analytics code

- admin/includes/configure.php

 

What others need to be unique?