I've inherited an application written using the Yii PHP framework. I've uploaded all the project files to a remote server, but I don't have SSH access or shell-exec permission.
Is it possible to make the application work in these circumstances?
If so, what files do I need to edit and in what way please?
Yes, it should be portable, all you need is just copy all project contents (including dependencies) to the destination folder and make proper configuration for a web-server.
The only one issue here is #app/runtime and #app/web/assets folders -- the should be accessible to write for web-process (the second is only if you are using AssetManager).
You can solve this issue in config, using runtimePath and assetManager['basePath'] parameters.
Regularly develop projects in PHP using Dreamweaver but I would start using Eclipse.
I have my machine in a directory where they are armaezandos projects, but also a place where projects are published in apache.
In Dreamweaver in the project settings I map the local directory, setting to perform the sending of files to the apache automatically after you save them.
I wonder what the correct way to develop with Eclipse.
If I map the project directly in the apache directory (thus having only one copy of the project) or if the Eclipse has some configuration to achieve the same functionality I have in Dreamweaver.
Another problem is that when mapping the project directly in Eclipse are created folders and files .settings, .buildpath and .project.
Note: Keep copies of two projects (one local and one in apache) for the purpose of tests not send files, uploads, etc. in memoento that you publish the project, and sending only the project folder location.
I use Eclipse Helios.
I use Apatana based off of Eclipse, pretty much the same way when storing projects. However I map my virtual hosts files to my project folders. I also keep revision control through Subversion so if any hiccups occur they can immediately be fixed. Just map your Apache Virtual Hosts files to your project folders.
Ok,
This seems like something that would be obvious, but I haven't been able to figure this out.
I just started using Solar PHP5 Framework http://solarphp.com. It is a great php5 framework. But with any new framework the is a learning curve.
Issue: Solar uses many pre-written scripts to make directories and files for you. Making it easy to rapidly deploy a site. Being that it uses these scripts, it makes symbolic links to files and directories. (Example: Chapter 1 in the manual) This is great until you need to export your entire root directory to upload to your server or make another instance on another development computer. The problem for me is, when I do this, the files are editable, but do not reflect any changes when I refresh a page. Its like it doesn't update any code. The only way I can accomplish changes or updates, is to (essentially) run the site set-up each time, which involves running all the setup scripts, setting up the DB connections, etc. This is a total pain.
Question Is there any advice out there on doing this where I can just export the working root directory, to easily upload to server or other dev machine, without having to run those scripts over and over again. I know its something easy but I do not know exactly what to search for.
Is the a certain method for exporting directories/files that use symbolic links?
You might try using rsync instead of ftp to deploy the site. rsync will respect symlinks. Of course you will need have ssh access or mount the server over ftp/sftp with FUSE. If youre using SVN you could also ssh into the server and do an svn export or checkout.
What is the best way to deal with config / directory / OS differences using SVN to develop and deploy on 2 different platforms?
I am developing in Windows and deploying to Linux.
I'd like to use my home PC to test the files before using commit, I'm using a web framework and you must specify the paths to your system and application files for the framework. Obviously those are different on the 2 machines.
I have the option of using a linux server at home, as a last resort. I really like working with SVN using a GUI right now since I am new to SVN web development.
So what would be the best solution to config differences between my development and live servers?
There has got to be an easier way then changing the file everytime I commit it to the live server, which is really against what SVN is trying to accomplish in the first place.
One option is to keep the configuration files out of the repository - set them up on their own for both your local and server machines, and then don't touch them again unless you have to. (Using the svn-ignore: property can keep you from accidentally adding the config files to the repository later on.)
Another option is to try to use relative paths and then have the config/etc directories be in the same relative location to the working directory, even if they're not in the same absolute locations.
You can set a svn-prop (property) to ignore the config file. Forcing you to create one (manually or generated) specific to every installation.
I have created a PHP web-application.
I have 3 environments: DEV, TEST, PROD.
What's a good tool / business practice for me to move my PHP web-application code from DEV to TEST to the PROD environment?
Realizing that my TEST environment still only connects to my TEST database; whereas, I need to PROD environment to connect to my PROD database. So the code is mostly the same, except that I need to change my TEST code once moved into PROD to connect to the PROD database and not TEST database.
I've heard of people taking down Apache in such away that it doesn't allow new connections and once all the existing connections are idle it simply brings down the web server.
Then people manually copy the code and then manually update the config files of the PHP application to also point to the PROD instance.
That seems terribly dangerous.
Does a best practice exists?
1) Separate configuration from the rest of the code. The rest of the code should then be able to run on all 3 locations without modifications. A typical config file could be:
<?
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123";
$site ="example.com";
$htroot = "/var/www/prod/htdocs"
?>
And for the test environment:
<?
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123";
$site ="test.example.com";
$htroot = "/var/www/test/htdocs"
?>
Do not include the configuration files with the passwords in the code base. The code base may be copied through insecure connections or be stored on third party code hosting servers later (see below). And you maybe don't want your passwords on all your backup disks of the code.
You could also create one single config file and use a switch depending on the environment the code runs:
<?
$site = $_SERVER["HTTP_HOST"];
if ($site == "example.com"; ) {
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123";
$htroot = "/var/www/prod/htdocs";
}
if ($site == "test.example.com") {
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123";
$htroot = "/var/www/test/htdocs";
}
?>
But now you could be tempted to put it back into the code base, which is less secure as explained above. And if you do not put it there you have to update 3 files, or use one fixed location per server, and you have to make sure the code finds the file on each server. I personally prefer the one-file-per-site solution from above.
2) You have already "versions". There is one version running on prod now. Give it a unique name and number, which will never change again. You can use that version name when you backup the code and when you refer to the version or when you move it somewhere you name the subdiectory that will contian it after the version.
The version that you will put on prod in the near future is a different version, and if you make changes again this is also a different version.
As a rule of thumb: increase the version number when you move or export the code, when you swap or exchange or upgrade between locations, when you make a demo, and after each feature or milestone and each time when you do a full backup.
Please note that the config files (3, one for prod, test and dev) are NOT part of the versions. So you can "move the versions around" but the not the config files. If you can, put the config files OUTSIDE the tree with the rest of the code, so you do not need to separate them and take care when you move around the versions later. You could move the config one directory "up" and access them from the files like this:
"include ../config.php";
3) If you want to use version control systems, they do a great job but it needs some time to get used to it and if you are in a hurry with your update it is probaby not the right time to start live with it now. But I would for the future recommend to use a latest generation distributed version control system. Distributed means you do not need to setup a server and many more advantages. I will name bazaar, if it is necessary to update over ftp it can do. Please note that a version control system makes exchanging a version very fast, because only the differences between the versions are written. Bazaar has a community and documentation which makes it easy to start. There is also Git, which has the most up to date commercial hosting site: http://github.com. You can view the code online and compare between the versions and there are many more helpful features, even if you are the only coder, but in a group it is even better. The choice between the systems is not easy. I can not recommend CVS, which is outdated. Also SVN is not the latest generation of distributed version control system, I would not recommend to use it if there is not a specific reason, and it will pollute all your subdirs with special subdirs, which can be annoying. For peolple who are used to it and have already code in it it is fine, but for a starter I would say don't.
There is also Mercurial and Darcs among the distributed and open source version control systems. Mercurial also has a great commercial site for collaboration and online code view (http://bitbucket.org).
4) As long as you do not use a version control system, how about using symlinks?
You could have a directory on the server src/versions/ somewhere and put the named versions in there, each one in their own subdirectory. You will only add versions (because a version that exists will not be changed, if you change it it becomes a new version)
You could have src/versions/v001/ src/versions/v002/ src/versions/v003/ or whatever naming scheme you use.
Now here comes the trick: /var/www/prod/htdocs is a symlink to src/versions/v001/
When you upgrade to v002 you just do the following:
shutdown apache
remove the old symlink /var/www/prod/htdocs (at this point the apache webroot is gone!)
create the new symlink /var/www/prod/htdocs being a link to src/versions/v002
start apache
You can also write a script for this with parameters and call it like this:
upgrade-web prod 002
This makes the gap even shorter.
Sometimes you have to do a "fallback", when you find out that the new version has errors in production and you have to go back. This would be easy (because you do not remove the old directories, you just stop apache, delete the symlink and re-create it to the former location, in this case src/versions/v001 )
And if test and dev is on the same server, you can of course also symlink the same directories, so there would be no any for move or copy.
5) If you do it manually without symlinks, why not move instead of copy?
(When the files are not yet on the same server, you can copy them somewhere near, and then start with the migration, so you do not have to stop the server for such a ling time)
If there are several directories on the root level of the project you could move them one at time. Be sure to NOT MOVE the config files. Or find some strategy to bring them bakc. Workflow would be:
Stop apache
Move away all current prod directories and files on the root level except config file(s)
Move all new prod directories and files to the root level except config file(s)
Start apache
6) try to find your perfect individual file and directory layout and perfect workflow. This takes maybe some time and some thinking, but it pays. Do it on a piece of paper until you find the best solution. This could mean that you have to refactor your code and change server config files, but for the future your life is easier when you do administration and upgrades. From my experience: do not wait so long with this step. Your layout shoudl nmake it easy and safe to upgrade. Upgrading is not somehting extraordinary, it is routine and it should be safe and simple to do.
7) If you name your server and workstation environments (operating system of server is linux I guess, but is it a hosted or a root server, do you have ftp acces or also shell (ssh) access, or sftp? where do you develop, on a windows machine, or a mac?) then people can name tools to do the copying and moving. Also interesting: Is the test and dev server the same machine, if not, how they are connected, or they aren't? If not, you would make a 3-way transfer (Copy it to your local workstation and then to the server).
8) Think of file permissions. If you move files around or copy them, maybe the file permissions change, and if the application depends on some of them there should be a way to check and maybe chang. Example: Some applications need writable directories where they put uploaded files or session files or template caching. Other applications do not allow some files for security to be writable.
Use configuration files to determine what database you're connecting to. That is, have a DEV configuration file, a TEST configuration file, and a PROD configuration file. It's generally the best way to avoid costly and frustrating mistakes.
Actually, I don't see any reason why TEST environment should miraculously migrate to PROD without any server shutdowns. TEST production is supposed to be for testing purposes. And even if you are actually TESTING on production server, bring it down (shutdown apache), change one line in your main config file, that is determining what set of minor config files to use) and bring it up again (start apache). This will take not more than 1-3 mins to complete and since you surely not going to do that twelve times a day, you will be fine.
Have your code in a revision control system (I prefer Subversion (svn)). This makes it easy to keep your DEV, TEST and PROD environments in sync, you don't have to keep track of files you modified. Once you are happy with your modifications on DEV, you commit the changes to svn and then run "svn update" on the TEST and eventually after testing on PROD server. Most linux hosting providers have svn client installed or you can install it yourself.
I don't like having a different version of a config file for each site because it requires manually renaming one file and removing the other two. I prefer having DEV, TEST and PROD configurations in the same config file. In the config file I determine which server the code is running on by checking either the hostname or the request url. Then I can have "if" or "switch" statement that would load configuration settings based on which server is currently running the code.
You might also need to sync database structure between your servers. I use sqlyog for this purpose, it has a built-in database structure synchronization tool that compares 2 database structures and prepares SQL to synchronize them.
When we push updates live, it's not often we have to reboot apache. This maybe a side effect of not having high traffic sites (< 1M pagedraws a month).
We have 3 branches, for various stages of development/QA: alpha (bleeding edge but available for viewing by non-developers and testers), beta (somewhat frozen for a particular release, final QA phase) and live (production).
To migrate from one branch to another, we perform a merge between say alpha and beta, commit that merge. Then run a deployment script which updates the branch from SVN on our development machine, then rsync's the code web servers to the beta document root.
As already mentioned by others, each branch can contain it's own config file with appropriate settings to cater for environment differences.
We are in the process of migrating to git to smooth out the branch merging process, which can be a little traumatic in SVN for large projects/releases.