Deploy*

When you don’t hear much from a developer it’s usually because he is hard at work at programming. At this time not everything is finished and tested, but here are some for sure upcoming features for 1.4:

• 2 new built in functions that make it easier for non programmers to add and create files
  • create_empty_file() creates an empty file into the generated deploy. Simply specify the path and file name. E.g. ( create_empty_file(’css/mystyles.css’); )
  • import_file() will copy a file from any directory from the root into the generated deploy. To use simply tell it what file you want to copy and then where. E.g. ( import_file(’files/CSS/mystyles.css’,'css/mystyles.css’); )
• Added the following JavaScript libraries:
  • jQuery UI
  • Prototype
  • script.aculo.us
  • MooTools
  • Dojo
  • SWFOject
  • Yahoo! User Interface Library (YUI)
• Now has a choice of header.php, footer.php, navigation.php, and sidebar.php includes.
• Deploy* now does not use a hard copy of jQuery. It now uses Google’s AJAX method. This is the same as all the generated deploys as well. This way they will stay up to date automatically among many other benefits.
• Fixed a bug that happened ≈0.2% of the time where a file wouldn’t be copied using the exec(cp) function. Instead I use a the custom function called import_file().
• I have updated the reset.css and how it handles resets. It now adds a @import into the main.css file. Some updates to the CSS file are:
  • <b> and <strong> are now bolded by default
  • <i> and <em> are now italicised by default
  • Links in no longer have a dotted outline in some browsers
  • No longer minified for easier editing

There are many more changes and cleaner javascript code that runs the Deploy* form and I’ll make sure to add a changelog.txt file to the Deploy* 1.4 file. I’m also going to include a tarball of Deploy* as well as a zip on code.google.com for the users who want to upload it to their server.

Even if you are not a programmer you might wonder how exactly does Deploy* work? Does it just copy files over? Does it create them on the fly? Is it magic?

As of 1.3.2 and under Deploy* goes through a few processes before making that final zip you get at the end after you push that big red “Deploy!” button.

The very first thing it does is creates a temp directory inside the root of Deploy*. This directory is “deploy_” then it adds the date, in UNIX time, and then a set of random numbers. This way, even if two people create Deploy*s at the exact same time the chance of them overwriting the others Deploy* is extremely slim.

Once the directory is chosen it checks to see if you chose a project name and if so what and what the file extension should be (if you chose the .php extension it would change index.html to index.php at this time). It also adds the DOCTYPE you chose into a variable for later.

If you chose to include a blank css file it creates a CSS file from scratch with PHP. If you choose include the resets it grabs the file from the /files directory. It places either the blank or reset file into your temp directory. It then saves that you chose CSS in a variable for later use.

Next, if you chose jQuery, it looks for the correct type of jQuery file to include such as the packed or uncompressed and then copys it into the temp directory. It then adds this choice to a variable for later.

The plugin part is next and if you chose plugins the process is probably one of the most tricky parts of Deploy*. I wanted to keep it easy for people to download Deploy* and add their own plugins with XML. The XML is basically in a v0.9 stage at this point and needs to have more flexibility to it.

The XML allows multiple images and stylesheets. It allows a space for a developer to put a link to his site and of course name his plugin. projectdeploy.org/plugins.xml Is where the XML that runs this Deploy* is now.

PHP runs through each choice and then runs through and copys all the files it needs into the right locations (e.g. <image>s get put into the /images in your Deploy* and <css> in the /css directory and the actual plugin file in the /js.) Finally it puts all the names of the plugins you chose into a single variable.

After this is all finished it creates that index.php file by putting all the info it needs into the final variable which holds all the previous variables above and creates a brand new file. So, for the DOCTYPE, <head>, <script>s, and everything depend on your previous choices.

The last thing it does creates any extra directories you chose such as flash, images, or includes. Deploy* is smart enough to create the images or css directory if your plugin requires it and you chose not to include those directories.

Now for the fun part, once everything is the way it should be when they unzip it, it copies this directory (deploy_xxxxxx) into the /deploys directory. It then copies itself inside of itself renames it to your project name and then zips that directory. You end up with raw project folder with the name of like deploy_xxxxx with all your files inside of it, a directory named your project name with all your files and a zip of your directory which becomes your final Deploy* which you end up downloading.

It goes through this process every time you visit the deploy.php page. It has gone through this around 12,000+ times at the time of writing this.

Hopefully this will help people when they download this and start developing on it which some have been doing. Not knowing about the temp directory makes it very strange when you are getting mkdir errors in your root directory when you think it supposed to be creating the directories inside of /deploys

The people who don’t like Deploy* usually have one comment, “Why would I use Deploy*? What it does is pretty trivial. I can just make a directory and copy it.” My response is always about the same and it’s basically, “Yes, you can.”

Now with that in mind, why would you use Deploy*? For me it’s a couple reasons:

1. I have never got around the creating a basic structure of a site I like that I end up copying. I should have, but never did. I ended up loosing where I put my code from prior projects and spent time hunting down those plugins.
2. I never had quite the same project. Sometimes I needed files while other I didn’t. I didn’t like having to copy the folder and then add and delete files from it.
3. I hate having to open up Finder in the Mac OS X and looking for a directory (Quicksilver speeds this up a little), but still opening Finder and going through looking for the folder with the different set ups and then looking again for the right one. I like being able to just click a bookmark and having the project instantly.
4. I didn’t like looking up/copy the proper DOCTYPE syntax and I also didn’t like having to link each piece of JavaScript I had. This was just a simple solution.

I guess you could call me lazy, but then again, you are calling the 10,000+ return visitors last week lazy as well.

The Road to Deploy* 2.0 seems far away from now, but I want to share some ideas I have for 2.0. I will not share all of the ideas because it would take the fun off the 2.0 release.

The main request I get is “can you include X file”. Yes, I could keep adding file after file, but then Deploy* 1’s simplicity, which in a little over a week has generated almost 10,000 project frameworks, would diminish. The very thing that has attracted my little app to so many would slowly cease to exist and be overrun by long drop down menus and continuous yes and no questions.

This is where Deploy* 2.0 will come in. The day this is released, Deploy* 1 will not be gone. It will remain on http://projectdeploy.org on the home page. What 2.0 will add is the ability to create your very own frameworks from scratch or with the help of prebuilt templates/frameworks/files. You will be able to upload files and then save the project to come back to later.

The simple users, such as slicers or designers wanting a quick mock up, will be able to use what will be called Deploy* Lite. No log-in will be necessary and in all reality Deploy 1.x will be equal to Deploy Lite.

Deploy* 2 is in the process of GUI design. As designs finish I will upload them to give you sneak peaks of what it will look like.

Please, as always, send any requests you have to http://projectdeploy.org/help

Fixes a validation error for HTML 4.01 Strict and HTML 4.01 Transitional users by removing a slash at the end of self closed tags.

If something isn’t working correctly let me know at projectdeploy.org/help. I tried doing as many possible combinations and it seems to be working fine, but I might have missed a certain combo.

This fixes the “Permissions Error” and adds some functionality to the Fluid side of things:

• Deploy* would display an error if the root folder was not set writeable, or 755, but Deploy* will take care of permissions now for both the root and deploys folder.
• Deploy* will now catch the “Permissions Error” and highlight in bright yellow what you need to do if the chmod() function fails AND you haven’t changed the permissions manually.
• Fluid users had a navigational bar like the normal site. That has since been hidden. If you want it to display you can change the CSS with your SSB’s preferences. It’s just set as display:none; right now.
• Small cosmetic fixes
• Added a “INSTALL.txt” file with directions on how to get it installed. It’s only 1 step now with version 1.3.1

It will now (version 1.3.1) change the permissions automatically with the chmod() function.

One user (possibly more?) had an issue installing this, which is my fault for not providing better documentation on how Deploy* works (I have added an install.txt file in Deploy* 1.3.1), however, that is another post. The error will read something like:

warning: mkdir() [function.mkdir]: permission denied in /home/user/public_html/mydeploy/deploy.php on line 138

warning: fopen(deploy_231202302/index.html) [function.fopen]: failed to open stream: no such file or directory in /home/user/public_html/mydeploy/deploy.php on line 298

To fix this is quite simple and I have been able to recreate it and fix it with ease. Set BOTH the “deploys” directory (a child directory of the root directory where all deploys are stored) AND the root directory, which in the example above would be “mydeploy” to 755 permission.

If you want help on changing permissions please consult your FTP’s user guide or if you are doing this without an FTP (like using MAMP on Mac OS X) consult with your OS user guide on file permissions.

For Transmit users, like myself:

• Right click on the directory you want to change the permissions of
• Click “Get Info”
• Type in 755 in the “octal” input
• Press “Apply”

This will be pretty close to most FTP applications and remember you can use your FTP application to browse your local HDD and change file permissions just like you are on a server.

1.3.1 now catches this error and provides an error message of it’s own if this happens.