Remote Debugging with the Zend Debugger and PHPUnit

1 Comment

I’m trying to do some remote debugging with PHPUnit on a remote system.  I was following the rules I had written about in a previous article but for some reason I could not get path mapping to work.  So I figured I’d ping the Studio lead developer because as soon as I did that I’d get it to work.  Well, that’s what happened.  It turns out that some of the debugging URL parameters seem to mess up the remote path mapping feature in Studio when working over the CLI.  What I found works is this.

export QUERY_STRING="start_debug=1use_remote=1&debug_port=10137&debug_host="

The original_url parameter is important because that’s how the path mapping maps the path to the proper project.

Debugging a PHP CLI script


I’m working on some code on the command line that I needed to debug.  It’s on a remote machine (well, a VM that doesn’t have a GUI) and so I needed to initiate a remote debugging session from the command line to go to my local copy of Zend Studio.  Thankfully, it’s pretty easy.  Since I need a place to store this command so I can copy and paste it onto the CLI I figured I’d simply blog about it.  Simply execute  this command prior to executing your PHP script.

export QUERY_STRING="start_debug=1&debug_stop=1&debug_fastfile=1&

The only thing you will need to change is the debug_host setting and perhaps debug_port.  Run your CLI script and the debugger will attempt to connect to your local Zend Studio instance.  If you want to discontinue debugging you execute this command.


Creating deployment packages with Zend Studio 9

Leave a comment

Deploying your work in Zend Studio is quite easy.  You have the ability to deploy directly from your IDE, which is, in general, more for local environments, the Zend Developer Cloud or testing.  The reason for this is because generally the developer should not have access to production.  Therefore, the drag and drop deployment that Zend Studio supports is usually not going to be used, though in smaller development shops it may still be quite useful.

The deployment mechanism in Zend Server uses a ZPK file, which contains the source code, assets and the deployment descriptor.  The deployment mechanism on the server side has already been discussed on this blog.

When creating a deployment package the first you need to do is either create a new project with deployment support

or add it by right clicking on your project and selecting “Add Application Deployment Support”

This will allow you to then either drag the project onto a target to deploy it or, as we’re talking about here, allow you to export it as we’re going to show here.

The deployment.xml file is where all of the configuration information resides.  Double click on this file and you will get a display similar to this

Most of the fields are self explanatory but a few might require a few words.

  • Document Root – This is the document root (duh) which is relative to the base directory of the deployment.  Your project, in other words.
  • License – This is the relative path to a text file in the project directory structure that contains the EULA for the project.  During the deployment workflow in the UI the end user will be presented with this if the file is available and will be required to agree to it before proceeding.
  • Persistent Resources – These are items that you don’t want to have overwritten during an upgrade.  For example, cache directories.


There are several different types of dependencies you can specify for your application.
These dependencies will be checked prior to deploying the application.  If they are not satisfied then the application will not deploy.


There are several triggers that can be hooked into during the deployment process, each of which has a Pre and Post stage
  • Activate
  • Deactivate
  • Stage
  • Unstage
To set up a trigger simply double click on the stage that you would like to edit and a new file will be created for you.  In that file will be documentation on information on how to retrieve variables and parameters for your deployment scripts.
Speaking of variables and parameters, what is the difference?  There are two differences.
  1. Variables you cannot change during the deployment process.  What the value is in the deployment file is the value that you will get in the deployment script.  Parameters need to be specified during the deployment workflow and also have some validation that you can do on the entered values whereas with variables you do not.
  2. Both are accessible via getenv() during deployment but variables are retrieved with their names “as is” but parameters are upper cased and prepended with “ZS_”.  So if you have a parameter named “ugly_Duckling” it would be accessed via getenv(‘ZS_UGLY_DUCKLING’)


There may be files in your application that you want to include (really!?) or exclude.  You can specify those in the Package panel.


The last step is to export your project.  Right click on the project and select Export and choose “Deployment Package”.  This will output the project into a ZPK file that you can then upload to your Zend Server instance or Zend Application Fabric installation where it will be deployed to your website.  Lickety Split.


There are other panels there and other information that I have not included.  The reason for that is that it is either relatively self explanatory on not necessary from an initial “getting started” point of view.  Or because it’s Friday and I’m running out of time.  🙂
The deployment functionality in Zend Server was something that I have personally been waiting for for a long time.  This addition in Zend Studio now makes the circle complete.  Granted, there will always be more that we can do, but this was a feature that has long been needed and I’m quite glad that it’s here.

Connecting to through Zend Studio 9

3 Comments is the landing page for our new cloud offering.  Using the Zend Application Fabric you can build your applications in the same environment as you will be deploying your apps to.  The application is built on and you can then deploy it onto any platform where the Fabric is supported.

But how do you get started? has been built in a way where you can connect with any IDE.  With Zend Studio 9 that connectivity has been built directly in to the IDE.

Getting started is actually quite easy.

Step 1 – Create a new project

Step 2 – Give that project a name!

Unlike with local development it really doesn’t matter where you put the project, it’s not going to be deployed locally anyway.  By default you will be given two options, the document root of the local server or the workspace.


Step 3 – Configure deployment options

This is where you connect up with phpcloud.  You are not going to be deploying to a production server.  The DevCloud (the thing you’re connecting to) is NOT a production box (I will go over this many times until you GET IT! 🙂 ) .  The first time you deploy your application it will do a full deployment to it will do a full deployment.  Then as part of that deployment an SFTP connection will be set up and any time you save a file it will automatically uploaded.  The first full deployment is not done now, it is done later on.  This just sets it up.

If you do not have an existing connection set up for Studio you will need to enter in the username and password for as well as specifying your private key.  If you forgot to save the one that you were given you can always generate a new one from the UI.




Step 4 – Write Code

Ahhh.  Geek nectar.  Code.  Write some code.  If you have already deployed your application this code will automatically be uploaded to your container.



Step 5 – Launch the app

On the deployment page (double-click deployment.xml) click on the Launch a PHP application link.

Step 6 – Specify deployment params

Prior to launching the application you will need to specify the container that you want to deploy to as well as the URL.


Step 7 – Admire your work

Once the application has deployed it will be brought up in Studio’s default browser.