1. Create a new empty file called aptana.sh that you will use to launch Aptana.  I store my install of Aptana in /home/username/Applications/aptana so I created the launch script in /home/username/Applications/aptana.sh.
2. Put the following code in the empty file and save it.  It will become what is called a wrapper script for launching the Aptana application.  Change the paths to match your environment.

   #!/bin/sh
   export GDK_NATIVE_WINDOWS=1
   /home/username/Applications/aptana/AptanaStudio

3. Make the script executable.  You can do this by right-clicking it in gnome and selecting Properties -> Permissions -> Allow executing file as program.  For the purists: chmod +x /home/username/Applications/aptana.sh
4. Create a launch script.  For the sake of simplicity, I create a launch script for it on my desktop by right-clicking on the desktop and selecting Create Launcher.
   Name: Aptana
   Command: /home/username/applications/aptana.sh (browse to and select the script you created)

You should be able to use a very similar setup to fix mouse clicks in Eclipse as well.  Just change the paths and filenames where appropriate.  Keep in mind that the application for Aptana is called AptanaStudio whereas in Eclipse it is simply called eclipse.

You can now test your script by double clicking the launcher or running the shell script you created.  The mouse clicking problems should be fixed.

Originally posted on my friend’s website here.

Basically, you can build your PHP objects and use this tool to create test cases in order to ensure that future upgrades don’t break existing code. This is called Unit Testing.  Check it out.  I’d love to know how you like it.

The FormContact 1.1 system will allow you to handle most Form-To-Email functions required by a website. It can be set up to take all the submitted form data and convert it to a readable email format. It can be customized to send users to a “thank you” page once the form data has been filled out, and certain form fields can be marked as being required in order for the form to be completed.

It also has the added ability for sending an automated response to the person who fills out the form. Different responses can be used for different forms, and can even be personalized to the user, based on form fields they enter.

Click here to read more about the person who created these resources and is offering them for you to use.

Requirements: PHP 4 or 5

Features:
Form Submission
Convert form submitted data to an email which can be received by the webmaster.

Destination Email
Set one or multiple recipients of the email generated from the form data.

Required Fields
The form can be set up to require certain fields to be filled out before a successful submission can be made.

Followup URL
Send your website visitors to a “Thank You” page once they have successfully filled out the form on your website.

Automated Response
In addition to emailing the form data to the webmaster, the FormContact system can create a customized email response to be set back to the user who filled out the form, based on what data they have entered into the form. Excellent for followup of clients, adding that small extra touch of connection to let them know that they have been heard, and will be contacted further shortly.

Download: Click Here

Website Hosting

If you’re looking for somewhere to host your own web creation, we would highly recommend DreamHost. Offering 167 Gig’s of storage space, 1.6 TB of bandwidth, PHP, MySQL and a host of other features, they’ll most likely be more than adequate for your website needs. And with a 97 day money back guarantee you can’t go wrong! Visit DreamHost for more information about what they offer.

And now, we’re offering $50 OFF coupons as a special benefit to our website visitors. Click here for more information.

This is VERY useful when doing PHP development because as you develop your application you can commit versions of the files to the Subversion (SVN) repository and it will keep track of all the changes you have made. If necessary, you can even revert back to older versions.

One of the difficulties that I have run into while doing website development is how to keep the live remote website synchronized with my local working copy. This is especially true of WordPress installations where editors may be uploading new pictures or documents to the site on a daily basis. If you are not constantly downloading the latest copy of the website, your local copy will be out-of-date and may cause problems in your development.

Subversion to the Rescue:

However, I have come up with a relatively simple solution to this problem, which utilizes the controls within Subversion, to both back up the data on the LIVE website, as well as providing version control for all the site data as a whole. For the sake of simplicity, I will be using a WordPress website as my example, but the concepts here could be applied to essentially any website.

One of the useful features of Subversion is the ability to run what they refer to as “hook scripts” at different points in the versioning process. For example, an SVN repository can be configured to run a set of scripts directly after any data is “committed” to it. (sending data to the repository is called “committing” the data) For this example, this is exactly the functionality we are going to be using.

Before I go any further though, let’s go over some of the requirements for setting up a website and subversion repository in this way.

WARNING: The following tutorial could seriously damage/destroy your website and/or server if you don’t know what you’re doing. We take no responsibility for any problems which may occur from following these instructions.

We HIGHLY recommend that you not employ these ideas on a LIVE webserver until you have thoroughly tested things in a development environment and fully understand how things work. Proceed at your own risk. You have been warned!

Requirements:

1. You will need shell access to the server.
2. The subversion repository must be on the same server as the website, and you will need to be able to run subversion commands on the server.
3. The user which runs the subversion repository, must also have access to add and remove files from the live website.

Terminology:

Subversion Repository (SVN): The subversion repository which will contain all the website data. Needs to be located on the same server as the website and have access to the website’s files.

Local Working Copy (LWC): Term used to refer to the Working Copy of the SVN repository stored on your personal computer.

Remote Working Copy (RWC): You will need to be able to set up a remote working copy of the SVN repository on the same server as the website and SVN.

Setting it Up:

The first step in setting up a website to use SVN in this way, is to set up the SVN repository itself. I will not go into detail on how to set up an SVN repository, but for the sake of the article, let’s assume we can create the SVN repository at the path “/svnRepository/” on the remote server. We will create the subversion repository by typing the following on the remote server shell.

svnadmin create /svnRepository

The next important piece of the puzzle we need is the Remote Working Copy. Let’s assume that we can store the RWC at the path “/remoteWorkingCopy/” on the remote server. To do this, we will enter the following shell command:

svn checkout file:///svnRepository/ /remoteWorkingCopy/

Finally, we will make the assumption that you already have a website set up on the remote server, and it is located at the path “/www/”.

In order to set this up properly you will need to ensure that you can connect to the SVN repository. Though I will not go into the details of how to use Subversion here in this article, you need to be able to check out a copy of the remote SVN repository to your local machine.

Synchronizing the Website with SVN:

The next step in this process is to synchronize the current website with the SVN repository. To do this, we will be working on the server and will need to copy all the files from the website into the Remote Working Copy. To do this you would enter the following commands on the remote shell:

cp -r /www/* /remoteWorkingCopy/

cp -r /www/.ht* /remoteWorkingCopy/

These two commands should copy all files from the website over to the RWC. Now, unfortunately, the RWC doesn’t yet know what to do with these files, so we have to instruct it that all the files should be added to the SVN repository. We would do this with the following command:

svn stat /remoteWorkingCopy/ | grep ^? | sed s/^?// | xargs -r -i svn add “{}”

As indicated above, this command should prepare all files you have just copied to the RWC to be committed to the SVN repository. The final step is to run the actual “commit” command, and you would do that as so:

svn commit -m “Website Backup” /remoteWorkingCopy/

This command will go through the RWC and send all the new files you just added to the SVN repository where they are versioned and backed up.

Set Up Automatic Website Updates on POST-COMMIT:

We now have copy of the website stored in the SVN repository, as well as in the Remote Working Copy, but unless we take further steps, these filesystems will very shortly be out-of-date with the LIVE website. We also don’t yet have a way to get changes that we make to the SVN files back onto the website.

In order to do this we will need to set up a POST-COMMIT hook script. This is a script in the SVN repository which runs after every time a commit is called. In order to install the script, simply place it in your /svnRepository/hooks/ folder and make it writable. The script is as follows:

#!/bin/sh

# POST-COMMIT HOOK

# Website BasePath
BASEPATH=”/www”

# Repository Path
REPOSITORY=”file:///svnRepository”

# Remote Working copy
LOCALWC=”/remoteWorkingCopy/”

REPOS=”$1″
REV=”$2″

# Update the current working copy
echo “Updating the working copy ” $LOCALWC
svn update $LOCALWC

# Propogate deletes, adds and modifies from the SVN repository to the website.
echo “Doing Deletes!”
svn log -qvr $REV $LOCALWC | grep “^ D” | sed “s/^ D //” | sed -r “s# \(.+\)##” | xargs -r -i rm -rf $BASEPATH{}

echo “Doing Adds!”
svn log -qvr $REV $LOCALWC | grep “^ A” | sed “s/^ A //” | sed -r “s# \(.+\)##” | xargs -r -i svn export –force $LOCALWC{} $BASEPATH{}

echo “Doing Mods!”
svn log -qvr $REV $LOCALWC | grep “^ M” | sed “s/^ M //” | sed -r “s# \(.+\)##” | xargs -r -i svn export –force $LOCALWC{} $BASEPATH{}

# Copy current website files to current working copy
echo “Copying current website files to working copy”
cp -r $BASEPATH/* $LOCALWC
cp -r $BASEPATH/.ht* $LOCALWC

# Automatically add all added and changed files from the website to the SVN repository.
echo “Adding and changing files”
svn stat $LOCALWC | grep ^? | sed s/^?// | xargs -r -i svn add “{}”

# Commit changes from working copy to SVN Repository
echo “Running commit”
svn commit -m “Website Backup” $LOCALWC

When you put this script in your /svnRepository/hooks folder and make it executable, the script will be run every time you commit something to the repository. Here is an outline of what it does:

Steps in Detail on Commit:

1. User runs UPDATE on their local machine to get latest info from repository
2. COMMIT is called
3. UPDATE the remote working copy.
4. Check svn log for deleted files in the Remote Working Copy and remove them from the website.
5. Check svn log for added files and export them to the website.
6. Check svn log for modified files and export them to the website.
7. Copy all live website files to Remote Working Copy.
8. Add all new files to be versioned in the RWC.
9. Commit all additions and changes from the RWC to the SVN repository.
10. The next time the user runs an update, it would get the latest files from the repository which should be synced to the website.

Conclusion:

The end result of this process is that when changes are made on your local machine and committed to the SVN repository, the script will run, it will synchronize the website with the RWC and then will deploy your changes TO the website.

I hope you have found this tutorial useful. As mentioned above, be very careful as you work through the process of running these scripts and commands, as you could potentially cause major breakdowns on your website. Again, we take NO RESPONSIBILITY for any problems which may result from following this tutorial. Follow these instructions at your own risk.

I would love to hear any feedback you may have about this article. I would also like to hear from developers who may have more experience with this topic than I do and would be willing to make suggestions for improvement.

References:

1. Subversion (software) – From Wikipedia, the free encyclopedia

If you have any suggestions for improvements or comments about it, feel free to leave them in the comments area below. Also, we’re always on the look out for good regular expressions, so if you feel that you have one or a few that might be useful to the other visitors to this site, feel free to mention them in the comments.