Setting your deploy via variable to remote cache in the configuration section of your deployment recipe allows you to keep a cached copy of your repository online, and subsequent calls to cap deploy will update the remote cache and copy it across to a new release.

There are no local checkouts, no need for your Internet connection to be the bottleneck, and no need to do any fancy setup.

The first time you run a “cap deploy” the script will check for the existence of /shared/cached-copy/ The directory will be created with a checkout of the latest revision if it doesn’t exist.

In your deploy.rb

set :deploy_via, :remote_cache

Just remember that this copies the repository verbatim, and is not the same as using svn export. So you’ll need to make sure you’ve setup Apache to protect your .svn directories:

<Directory ~ “^\.svn”>
Deny from all
</Directory>

If you’re getting these sort of errors when trying to use DOMPDF in Zend Framework 1.9.x …

Warning: include(DOMPDF.php) [function.include]: failed to open stream: No such file or directory in /home/myusername/library/Zend/Loader.php on line 83
Warning: include(DOMPDF.php) [function.include]: failed to open stream: No such file or directory in /home/myusername/library/Zend/Loader.php on line 83
Warning: include() [function.include]: Failed opening 'DOMPDF.php' for inclusion (include_path='/home/myusername/application/models:/home/myusername/library:.:/usr/lib/php:/usr/local/lib/php') in /home/myusername/library/Zend/Loader.php on line 83

And you’ve already tried the solution which has been written about a gajillion times:

require_once('dompdf/dompdf_config.inc.php');
spl_autoload_register('DOMPDF_autoload');
$dompdf = new DOMPDF();

Then I suggest you use the Zend_Loader_Autoloader::pushAutoloader() function, it’s really simple to use in the case of DOMPDF,

First we get the autoloader instance, then we push a new autoloader onto the stack giving the callback function as the first parameter and the namespace as the second. In the case of dompdf there is no namespace so just set it to an empty string.

Like so:

require_once('dompdf/dompdf_config.inc.php');
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->pushAutoloader('DOMPDF_autoload', '');

Note that we have to include the dompdf config file so the autoloader knows about the dompdf autoload function.

There are a bunch of resources available for Zend Framework, which is one of the reasons it is such a great platform to develop on.

I have found blogs to be indispensible through learning ZF, here are zend framework bloggers I follow,

1. Matthew Weier O’Phinney: http://weierophinney.net/matthew/plugin/tag/zend+framework
2. DASPRiD’s: http://www.dasprids.de/
3. Steven Macintyre: http://steven.macintyre.name/category/technology/zend-framework/
4. Ralph Schindler: http://ralphschindler.com/
5. Rob Allen: http://akrabat.com/

Ace.

Instead of manually changing the line in index.php to ‘development’ or ‘production’ every time you upload, or commit your changes to repository you can easily set the APPLICATION_ENV using Apache on your local development machine, and leave index.php to default to ‘production’ meaning you no longer have to modify index.php

I use MAMP Pro for local development on my Mac so it was as simple as:

1. Open MAMP Pro and go to File -> Edit Template -> Apache httpd.conf
2. Add the following line to the bottom of the file, click save and restart the servers

SetEnv APPLICATION_ENV development

This works because the Zend Framework application checks to see if the Environment Variable has already been set, and if it has it leaves it alone:

defined('APPLICATION_ENV') || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));

You don’t need to do this on your server because your application will default to the production environment

If you get this message when trying to do something in SubVersion, like an ‘svn commit’

svn: Commit failed (details follow):
svn: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options
svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR is set, and no 'editor-cmd' run-time configuration option was found

All you need to do is set the environment variable in your .bash_profile. To do this, enter the following command in Terminal:

vim ~/.bash_profile

Press ‘a’ to go into INSERT mode and type in the following:

export SVN_EDITOR="/usr/bin/vim"

You can change the path to the editor of your preference, I’m just used to using vim

Check your changes by reloading Terminal and printing the SVN_EDITOR environment variable to screen

AntPro-2:~ antbrown$ echo $SVN_EDITOR
/usr/bin/vim

Now when you do something like ‘svn commit’ without any arguments it will load up vim so you can type your log message, when you’re finished type ‘:wq’ to save and quit the editor.

Easy as pie

This was rather silly of me,

I was trying to add this line to my .htaccess:

RewriteRule ^free/download\.php /free/download/pdf [NC,L]

Not realizing that the Rewrite Conditions were completely negating my Rule.

The following will not Rewrite the URL if the Requested Filename is a regular file (example download.php)

RewriteCond %{REQUEST_FILENAME} !-f

The solution of course is to use the Zend Router to do the redirection, it’s one of those fore-head-smacking moments

I added this to my application.ini and away it went,

routes.freedownload.route = 'free/download.php'
routes.freedownload.defaults.controller = 'free'
routes.freedownload.defaults.action = 'download'
routes.freedownload.defaults.type = 'pdf'

This was driving me nuts…

I kept getting ‘out of memory’ errors in Zend Studio from having too many projects open at a time, I tried setting the maximum allowed memory to 2048MB which really… I mean really… should be heaps… but apparently not.

So I decided to branch off the big projects into their own Workspace

1. Go to Switch Workspace -> Other
2. Create a new Folder for your workspace: Eg: ~/Zend/workspaces/MyCoolWorkspace
3. Zend Studio promptly quits

However… when you relaunch the studio it will launch with the newly created Workspace. You can now Import existing projects into the Workspace and be free from ‘out of memory’ errors.

So, the only way around it is to Switch Workspace, wait for it to quit, then relaunch. I’m using Quicksilver so the relaunching isn’t a big hassle.

Apparently this has been filed as a bug for Zend Studio 7, but I wish they would’ve got a stable 6.x version working before doing 7