So just to give you a background of what really happens when you are using Xdebug for debugging. Loading xdebug as a zend module allows it to hook into the execution of php scripts. This means that you can really send the module instructions to pause and resume the execution. Also since it hooks into the execution it has access to all the variables at the time of execution which obviously is very useful for debugging purposes.
Xdebug is called a remote-debugger because the client doesn’t have to run on the same server as the webserver (or php instance running the script). The client and server communicate via their own protocol which is either GDB or DBGp. We will be using DBGp since Eclipse PDT supports it out of the box. To start the session the script needs to be called with the parameter XDEBUG_SESSION_START and similarly to stop it, it needs to be called again but with the argument XDEBUG_SESSION_STOP. There are firefox extensions that will do that for you so its worth looking into it, however Eclipse PDT (and possibly Netbeans) does that for you out of the box. Once triggered the client/server communicate via the chosen protocol and you can see your values in the debug perspective.

So lets start off by configuring the server side of things. Lets have a quick look at some of the ini settings that I had show in my previous post and had mentioned they will be covered in the next post.

xdebug.remote_enable=On
xdebug.remote_host="172.16.110.1"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"

Lets walk though the set of parameters required:

• xdebug.remote_enable: This enables the remote debugging mode. This will enable triggering of debugging by passing the above mentioned arguments
• xdebug.remote_host: You can specify the client hostname or IP address. This will get the server to connect to this client to pass the debugging information. This can be handy when your server is on one box, your scripts are running on another one (via selenium for instance) and your debugging tool is running on another box. This might look like a limiting feature that it only listens to the IP address mentioned in the config. However you configure xdebug to be able to start debugging from a request coming from any other host by setting xdebug.remote_connect_back to 1. This will make xdebug use $_SERVER['REMOTE_ADDR'] find out where the request came from and talk to the client. This obviously means, DON’T TURN THIS ON IN PRODUCTION.
• xdebug.remote_port: This is the port at which xdebug tries to connect to the remote host. 9000 i usually the default value for most clients so its best not to change this unless you have to get around some crazy IT firewall rules.
• xdebug.remote_handler: Is to define the protocol to use. The default is dbgp so you can get away without having to make this entry unless you want to change it to the older protocol for some reason

That’s pretty much all you need to do from the server side of things. Obviously if you are using apache, then you need to reload the configuration so that the ini files get re-read again with the new settings:

$ sudo /etc/init.d/apache reload

The next step is to configure Eclipse to debug. Rather than explaining it, I am listing screen-shots of configuration from my eclipse editor. My current eclipse build is: Build id: 20090920-1017. Click on the individual images to see their bigger versions.

Setting default browser to System default rather than the internal browser as part of Eclipse.

Under PHP->Debug -> Select XDebug and click configure. Showing the options for xdebug

Editing Server information. This server is where the xdebug server is present. This is also the place where you configure your script mappings etc.

Setting up a new debug configuration

Script running in the debug prespective in eclipse. Notice the variables on the top right showing the values at its current state.

Here is a quick example for anyone interested in getting up and running with it.

<?php
require_once 'Console/CommandLine.php';

$parser = new Console_CommandLine();
$parser->description = 'A fantastic command line program that does nothing.';
$parser->version = '1.5.0';
$parser->addOption('filename', array(
    'short_name'  => '-f',
    'long_name'   => '--file',
    'description' => 'write report to FILE',
    'help_name'   => 'FILE',
    'action'      => 'StoreString'
));
$parser->addOption('quiet', array(
    'short_name'  => '-q',
    'long_name'   => '--quiet',
    'description' => "don't print status messages to stdout",
    'action'      => 'StoreTrue'
));
try {
    $result = $parser->parse();
    // do something with the result object
    print_r($result->options);
    print_r($result->args);
} catch (Exception $exc) {
    $parser->displayError($exc->getMessage());
}

gives the output for yourscript -help

A fantastic command line program that does nothing.

Usage:
  tmp.php [options]

Options:
  -f FILE, --file=FILE  write report to FILE
  -q, --quiet           don't print status messages to stdout
  -h, --help            show this help message and exit
  --version             show the program version and exit

Details for options/configuration: http://pear.php.net/manual/en/package.console.console-commandline.options.php

Details for command line arguments: http://pear.php.net/manual/en/package.console.console-commandline.arguments.php

Details for extending lib: http://pear.php.net/manual/en/package.console.console-commandline.extending.php

rp@devbox:trunk$ php symfony --trace doctrine:build-all-reload --no-confirmation
>> doctrine  dropping databases
>> doctrine  Successfully dropped database f...octrine" named "secret_project"
>> doctrine  creating databases
>> doctrine  Successfully created database f...octrine" named "secret_project"
>> doctrine  generating model classes

  [Doctrine_Parser_Exception]
  Unable to parse string: Unable to parse line 0 (  

Exception trace:
  at ...
....

Then look no further, this was the oddest error message which caused errors inconsistently when generating models or updating the schema files. It turned out that the error was due to

• vim swap files
• osx ._ files

The parser would pick up all the files even if it started with a . (dot) which then borks of-course coz it wasn’t in the format it would expect it to be in

What would have been useful would be to have more meaningful error message like full path+file name and also the parser shouldnt pickup . (dot) files in the first place, dont see why a developer would want to keep his config files starting with a . (dot) unless its a .htaccess file.

This is what you would get if you have a similar problem:

% curl -k https://www.yahoo.com
curl: (1) Protocol https not supported or disabled in libcurl

The problem is that you would usually have something that depends on curl so you cant install the version of curl with its variant straightaway, so you will first need to remove the dependent first, then remove curl and clean up the install and then finally install curl with its ssl variant followed by its dependents.

The steps are something like this:

busybox:web rp$ sudo port uninstall curl @7.19.3_0 curl @7.19.3_0+ssl
--->  Unable to uninstall curl 7.19.3_0, the following ports depend on it:
--->  	php5
Error: port uninstall failed: Please uninstall the ports that depend on curl first.
busybox:web rp$ sudo port uninstall curl @7.19.3_0 curl @7.19.3_0+ssl
busybox:web rp$ sudo port uninstall php5
--->  Deactivating php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite
--->  Uninstalling php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite
busybox:web rp$ sudo port uninstall curl @7.19.3_0 curl @7.19.3_0+ssl
--->  Deactivating curl @7.19.3_0
--->  Uninstalling curl @7.19.3_0
--->  Uninstalling curl @7.19.3_0+ssl
busybox:web rp$ sudo port install php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite
Error: Requested variants do not match original selection.
Please perform 'port clean curl' or specify the force option.
Error: The following dependencies failed to build: curl
Error: Status 1 encountered during processing.
busybox:web rp$ sudo port clean curl
--->  Cleaning curl
busybox:web rp$ sudo port clean php5
--->  Cleaning php5
busybox:web rp$ sudo port clean php5
--->  Cleaning php5
busybox:web rp$ sudo port clean curl
--->  Cleaning curl
busybox:web rp$ sudo port clean php5
busybox:web rp$ sudo port install curl +ssl
--->  Fetching curl
--->  Verifying checksum(s) for curl
--->  Extracting curl
--->  Configuring curl
--->  Building curl
--->  Staging curl into destroot
--->  Installing curl @7.19.3_0+ssl
--->  Activating curl @7.19.3_0+ssl
--->  Cleaning curl
busybox:web rp$ sudo port install php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite
--->  Fetching php5
--->  Verifying checksum(s) for php5
--->  Extracting php5
--->  Applying patches to php5
--->  Configuring php5
--->  Building php5
--->  Staging php5 into destroot
Warning: php5 requests to install files outside the common directory structure!
--->  Installing php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite

If this is your first install, you might want
cd /opt/local/apache2/modules
/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so

* copy  /opt/local/etc/php.ini-dist to  /opt/local/etc/php.ini
--->  Activating php5 @5.2.9_0+apache2+macosx+mysql5+pear+sqlite
--->  Cleaning php5

I trolled through the svn manuals and some really interesting blog posts and summarizing the steps that I took to put my code base back into control. Its rather unusual that none of the steps below are anything special its just that I hadnt had to work on a situation where I had to work on a feature which might or might not see the daylight of being pushed to production.

So the first thing to do was to create the trunk, branches and tags directory.

$ mkdir ~/websites/secret-project/trunk \
            ~/websites/secret-project/branches \
            ~/websites/secret-project/tags

I now use dreamhost for my svn but you can replace this with any other repo (local or remote) to manage your code. So I would start by creating the initial directory structure in the repo.

$ svn import -m 'Importing the initial directory structure' \
                http://svn.rajatpandit.com/secret-project/trunk \
                http://svn.rajatpandit.com/secret-project/branches \

http://svn.rajatpandit.com/secret-project/tags

Now checking out the empty directory locally to setup the local directories we created locally.

$ svn co http://svn.rajatpandit.com/secret-project/trunk \
               ~/websites/secret-project/trunk

The next step is to ensure that you are always using the most recent version of symfony. I like this feature about svn. You can have multiple directories pointing to multiple repos, that we can always ensure that your project can benefit from the most recent versions. We start that by setting up the lib/symfony and marking that as having an external repo.

$ cd  ~/websites/secret-project/
$ mkdir trunk/lib
$ mkdir trunk/lib/vendor
$ svn propedit svn:externals lib/vendor
symfony http://svn.symfony-project.com/tags/RELEASE_1_2_4/

(1.2.4 being the most recent release at the time of writing this post)
This is a good time to commit this to the svn and get the latest code.

$ svn ci -m 'updating symfony to 1.2.4'
$ svn update lib/vendor

With the most recent codebase available in the vendors directory, now is a good time to do any sanity checks if you fancy.

php lib/vendor/symfony/data/bin/check_configuration.php
php lib/vendor/symfony/data/bin/symfony -V

If all works fine then there is one other configuration change that is required, after which you can start generating the basic stub of your code base. The change is to update the path sfCoreAutoload.class.php so that its picked up relative to where its placed.

require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';

With that done and your basic symfony apps and modules created, you can now update the svn configuration so that you can ignore the cache and logs directory.

$ rm -rf cache/*
$ rm -rf log/*
$ chmod 777 cache
$ chmod 777 log
$ svn add *
$ svn propedit svn:ignore log
$ svn propedit svn:ignore cache
$ svn ci -m "updating the codebase with new apps/modules"

Its also a good idea to ensure that the auto generated files dont make it to the repo, which is clearly a waste as its usually good to generate them on the server after deployment, that way you are usually sure about your configurations and settings.

svn add --non-recursive lib/model
svn add --non-recursive lib/model/om
svn add --non-recursive lib/model/map
svn propedit svn:ignore lib/model/om
svn propedit svn:ignore lib/model/map

You can also do the same for forms and filters any other auto generated file like sql files). Obviously needless to say, you need to commit your files as often as possible and tag after each release.

This post has been heavily adapted from a post on Stereo Interactive which is a blog I usually end up on when I get stuck on symfony problems. Worth reading it as well. This post would usually form as my own pointer when starting on the next project on symfony.

• List through items
• Create a temp array which contains the modified values
• Exit the loop and re-assign the new array back to the actual array.

This works fine, other than there are some problems with that.

• You need to create a temp array
• Make sure you assign it back to the original array (People make mistakes of not doing that assignment)

So here’s a simpler more easy way to handle this.

$items= array('key1' => 1, 'key2' => 12, 'key3' => 3);
foreach($items as $item => &$value) {
        $value += 20;
        print "$item: $value";
}
var_dump($items);

Note that the $value is assigned a reference, so it doesnt work on a copy of the value but the actual value and hence it retains its value even after exiting the loop. Saw this snippet in symfony so thought it was worth mentioning.

<a foo:param="bla">Some sample text</a>

Trying to access is using the following code didnt work for me:

$attributes = $xml->a->attributes('foo');
echo $attributes['param'];

However as mentioned in the manual I needed to explicitly specify that the attribute is prefixed using the second argument. The default value for the second argument is false.

$attributes = $xml->a->attributes('foo', true);
echo $attributes['param'];

I spent a while trying to figure this out, hope this saves you some time. Btw simpleXML is awesome.

So here’s the url that I was looking for. 

http://testsite.rajatpandit.com/university/Indian_institute_of_management_ahemdabad.html

I got to the point where I had functional code which gave me URLs like these:

http://testsite.rajatpandit.com/university/id/1

These are the steps to convert the URLs are humanly understandable.
Step 1:
Add additional field to the university table to store the modified name. So update the schema to addt the additional field.
[yml]
university:
_attribute: {phpName: University}
id: {type: integer, required: true, primaryKey: true, autoincrement: true}
name: varchar(256)
stripped_name: varchar(256)
website: varchar(256)
country: varchar(2)
city: varchar(256)
body: longvarchar
approved: boolean
created_at:
updated_at:
[/yml]

Obviously you would need to do the regular to regenerate the models.

#symfony propel-build-model
#symfony propel-build-sql
#symfony propel-insert-sql

or do it all in one easy step.

#symfony propel-build-all

Step 2:
Now modify the model to update the new column (stripped_name) every time the standard setName($v) is called. For that we need to have a helper function that does this. Here’s the code I used, you can use your own version.

function stripText($text) {
  $text = strtolower($text);
  $text = preg_replace('/\W/', ' ', $text);
  $text = preg_replace('/\ +/', '_', $text);
  $text = preg_replace('/\-$/', '', $text);
  $text = preg_replace('/^\-/', '', $text);
  return $text;
}

I create a new file called CustomHelper.php and store in under lib/helper/ and then update the model class for University to override the function setName($v) with the following function.

public function setName($v)
  {
    include_once('lib/helper/CustomHelper.php');
    parent::setName($v);
    $this->setStrippedName(stripText($v));
  }

That will ensure that the new column stripped_name gets updated.

Step 3:
Update your php template where you create the links to the following code.

<ul>
  <?php foreach($universities as $university): ?>
    <li>
      <?php echo link_to($university->getName(), '@university_display?stripped_name=' . stripText($university->getName())); ?>
    </li>
  <?php endforeach; ?>
</ul>

and update the routing.yml to match the routing name used.

[yml]
article_display:
url: /article/:stripped_title.html
param: {module: home, action: article}
[/yml]
The routing rule reads out like this,
When you see the url containing /article/<something>.html redirect it to module: home to its action article and assign a request parameter <stripped_html> to <something>.

and that’s all you need to do to get your urls look all nice and clean.