This has given me a good opportunity to evaluate both techniques and determine my personal preference for working.

The more traditional technique is to pass values to methods using individual parameters as in the example below:-

public function someMethod($name, $age = null)
{
  // do something
}

The benefit I have found with this method is that you can clearly identify what needs to be passed to the method, however, if you need to change the method to include an additional parameter it means that you have to update every call to this method so that every parameter is specified.

An alternative (and my personal preference) is to used an option array like in the following example

public function someMethod($options = array())
{
  $name = $options['name'];
  // do something
}

In this case, if you need to add an extra parameter to the method you can simply add the value to the options array and update the functionality within the method.  You do not necessarily need to update the calls to this method that are already in place  because they should still work fine provided the updated functionality is defined in such a way that it allows for the new parameter to be optional.

In addition, I feel that if you provide decent documentation regarding the options array (which should include a list of all the options values allowed), especially if it can be picked up via auto-completion in IDEs such as Netbeans, then this is just as easy to use as methods which are defined to accept individual parameters.

References

http://weblogtoolscollection.com/archives/2010/02/25/passing-parameters-as-variables-vs-passing-parameters-as-an-array/

The section I was working on was a form submission (within the wordpress administation) which saved the form values into the database and then redirected the user upon success to another page (using wp_redirect) but this resulted in a blank content pane.

This seems very strange to me as it showed some of the page contents i.e. the header and left navigation but the content pane was completely blank.

I searched around for a few hours trying various suggestions to similar problems, downloading other wordpress plugins and examining how they used the wp_redirect function to see if the authors of these other wordpress plugins had done anything different, only to find that there was no difference.

I eventually managed to figure out the issue after I read a post regarding a problem another user was having where they were getting a completely blank screen and another member suggested the problem could be due to whitespace which was sent to the browser before the redirect was called resulting in a “headers already sent” problem.

This got me thinking that I did not have output buffering enabled which was strange as I usually have output buffering enabled to resolve this issue, however, in this case I did not have output buffering turned on and this turned out to be exactly the problem. I added the following line to my .htaccess file and the redirection now works perfectly.

php_flag output_buffering on

I was glad to get this one resolved as I had to spend far too much time on something that I have resolved time and time again. Certainly one I’ll be aware of should there be a next time!

function get_raw_sql($query) {
    if(!($query instanceof Doctrine_Query)) {
        throw new sfException('Not an instanse of a Doctrine Query');
    }
 
    $query->limit(0);
 
    if(is_callable(array($query, 'buildSqlQuery'))) {
        $queryString = $query->buildSqlQuery();
        $query_params = $query->getParams();
        $params = $query_params['where'];
    } else {
        $queryString = $query->getSql();
        $params = $query->getParams();
    }
 
    $queryStringParts = split('\?', $queryString);
    $iQC = 0;
 
    $queryString = "";
 
    foreach($params as $param) {
        if(is_numeric($param)) {
            $queryString .= $queryStringParts[$iQC] . $param;
        } elseif(is_bool($param)) {
            $queryString .= $queryStringParts[$iQC] . $param*1;
        } else {
            $queryString .= $queryStringParts[$iQC] . '\'' . $param . '\'';
        }
 
        $iQC++;
   }
   for($iQC;$iQC < count($queryStringParts);$iQC++) {
       $queryString .= $queryStringParts[$iQC];
   }
 
    echo $queryString;
}

I hope that it proves useful.

I’ve started off by resurrection an old project that I worked on while I was self employed as Design2Host Ltd.  csNews Pro (formerly V-Desk Newsletter System Pro) has had a few cosmetic details changed (changed the name, removed the licence key limitions) but it’s exactly the same project and it is compatible with the paid version that was original available so you can easily convert from the previous paid version across to the free version when any updates become available.

Feel free to download and play with csNews Pro and feel free to give my any feedback on it.

While I am writing these actions I often find that I have to delete the contents of the MySQL tables as you can never write the routine complete and accurate in one go so as you build it up in smaller steps you find that you have to get rid of the previously old data.

This presented me with 2 problems:-

• Using DELETE FROM [TABLENAME] does not reset the auto-incrementing fields so if you have anything that is based on the id during the rest of the import then you’re going to have issues.
• There is a lot of clicking in phpMyAdmin to empty the tables, especially if you forget about the foreign key relationships.

I found that MySQL had a TRUNCATE TABLE but this is not directly available via Doctrine as the TRUNCATE TABLE is function of the type of database you are using and Doctrine cannot assume you are always using MySQL so therefore it cannot provide a generic method to call it.

Having said that it was not too difficult to run the TRUNCATE TABLE from within my Symfony project.  All I had to do was add the following lines of code to an action within the actions.class.php for my import module and now it empties each table I have defined before importing the data and it also resets the auto-incrememt ids all my tables start from id = 1 each time I run the import.

$doctrine = Doctrine_Manager::getInstance()->getCurrentConnection()->getDbh();
$doctrine->query('TRUNCATE TABLE order_items');
$doctrine->query('TRUNCATE TABLE orders');
unset($doctrine);

Be careful which order you run the TRUNCATE TABLE calls so you avoid the foreign key relationship issues.

Let me know if this helps you out.  Enjoy!

As my use of Symfony is increasing I find myself frustrated that there doesn’t appear to be an easy way to get the raw SQL from a doctrine query object so I can simply output it and paste it into phpMyAdmin to debug problems with the SQL. I may be wrong about this but as yet I have not found a built in function to perform this operation.

Sure I am able to output the query with the “?” indicating where the necessary values are to go and I can also easily output the array of query parameters so I can substitute these manually but this takes time and it would be much much simpler and quicker to just output the whole query with the substitution already done so it’s a simply copy and paste of the raw SQL from the doctrine query object straight into phpMyAdmin.

I have wrote a quick function to do this and I had meant to post this for a while but I just have not had the chance to get round to it until now.

The code for this is can be found below:-

function get_raw_sql($query) {
    $query->limit(0);
 
    $queryStringParts = split('\?', $query->getSQL());
    $iQC = 0;
    $queryString = "";
 
    foreach($query->getParams() as $param) {
        if(is_numeric($param)) {
            $queryString .= $queryStringParts[$iQC] . $param;
        } elseif(is_bool($param)) {
            $queryString .= $queryStringParts[$iQC] . $param*1;
        } else {
            $queryString .= $queryStringParts[$iQC] . '\'' . $param . '\'';
        }
        $iQC++;
   }
 
   for($iQC;$iQC < count($queryStringParts);$iQC++) {
       $queryString .= $queryStringParts[$iQC];
   }
   echo $queryString;
}

In my case this is a global function but it could very well be written as a static function in a debug class.

$query is a Doctrine Query object and this function iterates round the parameters for the query string and replaces each instance of a “?” with the corresponding variable. It has a crude (but fairly effective so far) method of determine whether it’s a string, number or boolean when performing this substitution and so far this works well in all the cases I’ve used it.

The $query->limit(0); is very important as the $query->getSQL() function does not work properly in this context if a limit is specified on the query so as we are wanting to debug the SQL and a majority of the time we are not concerned with the limit I have opted to remove this from this routine.

Hopefully this will allow you to save some time and effort trying to get the raw SQL from your doctrine query objects and I would appreciated any comments, thoughts or ideas you may have for improvement.

If you post a question and no-one managed to provide you with an answer do you:-

• post up your solution when you’ve found it? or
• simply forget about the post and leave everyone else to figure it out themselves too?

Unfortunately there are a number of people in the latter category (myself included from time to time) and being a web developer means I run into this type of issue more than I would like but, I’ve recently come across yet another great reason why you should go back and answer your own question when you have managed to work out the answer.

A few months ago I was working for Alienation Digital in Glasgow and I had a problem with creating a custom validator using a callback in Symfony and I posted the problem to the Symfony forums, and later, the solution I used to rectify the problem.

Fast forward a few months and you now find me working for Line Digital in Edinburgh and I’m now working on a new project which has a very similar problem. Obviously I don’t have access to the code I wrote while at Alienation Digital but unsurprisingly I had forgotten I have already solved this problem as it’s months since I had to last think about it.

So out comes Google again, I enter my search phrase and I am amazed that the first forum post (which resulted in the path to the solution) was my own post that I wrote while at Alienation Digital.

So the moral of the story is to answer your own posts, even if you do end up feeling like you’re talking to yourself because you the next person your post helps out may be yourself.

Fatal error: Uncaught exception ’sfConfigurationException’ with message ‘Configuration file "/usr/lib/php/symfony/config/config/core_compile.yml" does not have a registered handler.’ in /usr/lib/php/symfony/config/sfConfigCache.class.php:101

Looking into this a little closer we found that the server had ran out of disk space so after making some space and using “symfony cc” to clear the cache we thought that this would have resolved the problem, however we continued to get the “does not havea  registered handler” message being presented.

In the end, we had to clear the cache manually with a command similar to:-

rm -fr cache/*

For some reason this seemed to work fine where as the “symfony cc” command didn’t work therefore the only conclusion that we could come up with is that when the server ran out of disk space it corrupted something in the symfony cache which either is not normally cleared with a “symfony cc” and as a result we needed to remove it completely so symfony could re-build it automatically.

$monthName = $aMonth[$monthNum];

However, when I wanted to use PHP to display the month name this time I wanted to see if there was a better solution.

The one I came across was posted on The Code Cookbook and was a simple 1 line statement which was great… simpler, neater and far more elegant than my usual method and it looked like

$monthName = date("F", mktime(0, 0, 0, $monthNum, 10));

Normally I would have been happy with this, however was needing to deal with a month drop down box which didn’t run from January to December but instead ran from November to April but this worked out to be rather simple too.

Using PHP to display the month names from November to April was achieved simply by using the above statement in a loop and my first attempt looked like this:-

for($i=0;$i<6;$i++)  {
    echo date("F", mktime(0, 0, 0, (($i+11) % 12), 10));
}

As I was aware the months would be rolling over to the following year I have attempted to use the mod function to ensure the month values are valid.  The numbers for months, unlike days and years, run from 0 to 11 representing January to December respectively so the above loop works great, however it can be simplified yet again.

After one of my colleagues looked over this section of code they advised me that mktime will automatically round the date should you attempt to create an invalid date so the above loop can be simplifed to:-

for($i=0;$i<6;$i++)  {
    echo  date("F", mktime(0, 0, 0, $i+11, 10));
}

What I was expecting was:-

2009-11-01 = OK
2009-12-01 = OK
2009-13-01 = NOT OK

but instead the last of those 3 examples actually gave the value of 2010-01-01 which is a valid date and would mean that I would be able to display the month names November to April very very easily indeed!

Now that I’m aware of that I’ll not be going back to my old method for display month names in PHP!

Process

We followed the basic plan for the migration:-

• Copy magento files up to the new server
• Backup the database on the old server and restore on the new server and set the MySQL user
• Update the “web/unsecure/base_url” and “web/secure/base_url” keys within the core_config_data

This seems to work well for almost everyone we found asking for migration help on the forums but did not work for us.  We even tried updating the /downloader/pear/pear.ini to ensure any additional modules downloaded via Magento Connect would install properly (I have since found out you can simply delete the pear.ini and Magento Connect will rebuild it with the correct paths!)

Symtoms

After performing the above steps the site out only partically work… You ccould browse the site, use the administration pages, add a simple product to the cart but you could not add a comfigurable product to the cart nor could you update the quantities of the items already in the cart.  As you were able to add some products and not others this left us quite confused.

After checking that the folder permissions were correct, session files were getting written and trying the migration on 2 or 3 different servers (all of which worked except the new server) one of our colleagues manage to isolate the issue as being a problem with the virtual host configuration for the magento site.  As this configuration worked on all the other servers we tried we didn’t suspect that would be a problem but the new server must have been configuration to be more secure than the other ones we have been testing the migration on.

Solution

This fix was really quite simple… all we had to do was add the following line into the magento sites virtual host configuration:-

AllowOverride All

Now everything runs fine… and everyone is happy (and now a little wiser) again!